After having it implemented, it looks quite ugly (because files are removed from the distributed tarball and cannot be easily revived). Is there a reason why autogen generated files cannot run with an arbitrary libopts? I mean does the API of libopts change that often? If not it may be a good idea to require regeneration of the files only libopts API is different from the API used by autogen. Currently the #error condition is on every difference in major or minor release between libopts and autogen, and this is what causes the inconvenience.
regards, Nikos On Wed, Nov 6, 2013 at 8:28 PM, Nikos Mavrogiannopoulos <n...@gnutls.org> wrote: > On 11/06/2013 06:26 PM, Bruce Korb wrote: >> On 11/06/13 01:32, Nikos Mavrogiannopoulos wrote: >>> Hello, >>> I realized that is not easy to ship the auto-generated files of >>> autogen. That is if I ship them and the user has a different version >>> of libopts installed then he'll get something like:: >>> In file included from ocpasswd.c:31:0: >>> ./ocpasswd-args.h:61:3: error: #error option template version >>> mismatches autoopts/options.h header >> >> Yep. You must ensure that the headers in the included library >> are found *before* the system headers. What does the compile >> line look like? If it has -I/usr/include before -I$top_builddir/libopts >> you will definitely have a problem. The link line should also have >> $top_builddir/libopts/libopts.a in it. >> >>> # error option template version mismatches autoopts/options.h header >>> >>> If I include the libopts in the package and force the program to use >>> that and not the system one, then I have issues with people who have >>> autogen and regenerate them. >> >> If they regenerate stuff, they must also ensure that they compile and link >> against the relevant version of the library and headers. >> >>> Both cases are kind of ugly, and the only viable alternative seem to >>> be to not ship them at all and require autogen in the target system. >> >> That might work if all target systems come out of a foundry >> (is a distro). >> >>> This is of course is ugly for systems like *bsd that typically do not >>> have a lot of gnu tools (and autogen requires guile etc). >>> >>> Is there any other cleaner solution to that, that I'm missing? >> >> If compiling with -I$top_builddir/libopts early on and linking with >> $top_builddir/libopts/libopts.a does not work, I'd like to understand >> why not. :) That _ought_ to work... > > What I want to do is compile with system libopts if it exists and the > included one otherwise. Things work when the included one is used, but I > have the issue described above (incompatibility of auto-generated files) > if a system one is detected. What I am thinking, could work would be to > delete the auto-generated files if the system libopts is being used. > > Probably that could be achieved by checking NEED_LIBOPTS_DIR after the > CHECK_LIBOPTS macro. > > regards, > Nikos > ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Autogen-users mailing list Autogen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/autogen-users
