autogen-users

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

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

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
 # 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.

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.
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?

regards,
Nikos

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

[Bruce K. <bk...@gn...>]

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...

Cheers - Bruce

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

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

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

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
>

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

[Bruce K. <bk...@gn...>]

On 11/08/13 06:10, Nikos Mavrogiannopoulos wrote:
> 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.

Hmmm.  OK.  I'll pull your sources and if you'd send me your
fiddlings (patch), I'll look into what makes sense.  I'll try
to do something reasonable with your code, but fix my own and
re-release if necessary.

Thanks for your help!

Regards, Bruce

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

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

On Fri, 2013-11-08 at 08:28 -0800, Bruce Korb wrote:

> Hmmm.  OK.  I'll pull your sources and if you'd send me your
> fiddlings (patch), I'll look into what makes sense.  I'll try
> to do something reasonable with your code, but fix my own and
> re-release if necessary.

I have not done something special and I don't think what I have can be
easily generalized. What I've done (see also [0]) is:

========================code===========================
AC_CHECK_PROG([AUTOGEN], [autogen], [autogen], [/bin/true])

if test x"$AUTOGEN" = "x/bin/true"; then
        AC_MSG_WARN([[
***
*** autogen not found. Will not link against libopts.
*** ]])
NEED_LIBOPTS_DIR=true
fi

LIBOPTS_CHECK([libopts])
if [ test "$NEED_LIBOPTS_DIR" != "true" ];then
        dnl delete libopts-generated files (to force regeneration)
        rm -f ${srcdir}/src/ocserv-args.c ${srcdir}/src/ocserv-args.h
        rm -f ${srcdir}/src/ocpasswd-args.c ${srcdir}/src/ocpasswd-args.h
fi
========================code===========================

regards,
Nikos

[0]. http://git.infradead.org/ocserv.git/tree

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

[Gyepi S. <sel...@gy...>]

Pardon me for jumping in, but I think you can resolve the problem
by "hiding" your libopts generated files until you are sure you need
them at which point you can install them.

Assuming that your libopts files are shipped with a .txt extension (which
you'll have to add after they are generated), you could do something like this:

   if [ test "$NEED_LIBOPTS_DIR" = "true" ];then
           dnl install libopts-generated files
           for f in \
              ${srcdir}/src/ocserv-args.c ${srcdir}/src/ocserv-args.h \
              ${srcdir}/src/ocpasswd-args.c ${srcdir}/src/ocpasswd-args.h ; do
              mv ${f}.txt $f
           done
   fi

Rather than using a file extension, you can also place them in a separate
directory and copy them into place, etc.

Regards

-Gyepi

On Sat, Nov 09, 2013 at 09:36:46AM +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2013-11-08 at 08:28 -0800, Bruce Korb wrote:
> 
> > Hmmm.  OK.  I'll pull your sources and if you'd send me your
> > fiddlings (patch), I'll look into what makes sense.  I'll try
> > to do something reasonable with your code, but fix my own and
> > re-release if necessary.
> 
> I have not done something special and I don't think what I have can be
> easily generalized. What I've done (see also [0]) is:
> 
> ========================code===========================
> AC_CHECK_PROG([AUTOGEN], [autogen], [autogen], [/bin/true])
> 
> if test x"$AUTOGEN" = "x/bin/true"; then
>         AC_MSG_WARN([[
> ***
> *** autogen not found. Will not link against libopts.
> *** ]])
> NEED_LIBOPTS_DIR=true
> fi
> 
> LIBOPTS_CHECK([libopts])
> if [ test "$NEED_LIBOPTS_DIR" != "true" ];then
>         dnl delete libopts-generated files (to force regeneration)
>         rm -f ${srcdir}/src/ocserv-args.c ${srcdir}/src/ocserv-args.h
>         rm -f ${srcdir}/src/ocpasswd-args.c ${srcdir}/src/ocpasswd-args.h
> fi
> ========================code===========================
> 
> regards,
> Nikos
> 
> [0]. http://git.infradead.org/ocserv.git/tree

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

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

On Sat, 2013-11-09 at 13:02 +0200, Gyepi SAM wrote:
> Pardon me for jumping in, but I think you can resolve the problem
> by "hiding" your libopts generated files until you are sure you need
> them at which point you can install them.
> 
> Assuming that your libopts files are shipped with a .txt extension (which
> you'll have to add after they are generated), you could do something like this:
[...]
> 
> Rather than using a file extension, you can also place them in a separate
> directory and copy them into place, etc.

That's pretty nicer. It requires a dist-hook to make the .txt files, but
seems to work better.

regards,
Nikos