Re: [Autogen-users] Fwd: shipping the auto-generated files

[Nikos M. <nm...@gn...>]

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 <nm...@gn...> 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
>