Re: gnulib-tool changes

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> Yay!  I considered dropping use of gnulib in libgnutls yesterday,
>> because I wanted the error module for the tools, but that module need
>> a program_name variable.  When the library didn't provide one, there
>> were linker failures.  I added a dummy 'char *program_name = "gnutls"'
>> inside the library now, but it is not a clean solution.
>
> The solution that you can already apply today is to use two different
> invocations of gnulib-tool in different subdirectories of your package
> (so that they don't collide on the filesystem), with different
> configure.ac-s. With --macro-prefix you can cover both by the same
> configure.ac.

Yup, I'm using two configure.ac's in gsasl, but I don't want to change
gnutls to use the same scheme for only this reason.  And with your
work, I don't have to.

> The ChangeLogs can be disabled through --no-changelog. The backup files
> cannot be disabled. But you can remove them on your own afterwards.

Excellent!

>> > 1) Changed command-line invocation conventions:
>> >      "gnulib-tool --import abc"
>> >    followed by
>> >      "gnulib-tool --import def"
>> >    is equivalent to
>> >      "gnulib-tool --import abc def".
>> >    I.e. gnulib-tool memoizes the last parameters and reuses them.
>> >    "gnulib-tool --import" performs an update without changing the
>> > parameters.
>>
>> Idea: an "--import --disable abc" or something to remove a module?
>
> Then we would need also
>   --import --remove-lgpl
>   --import --remove-libtool
>   --import --remove-avoid
> These operations are not frequent. It's acceptable to tell the user to
> modify the gnulib-cache.m4 file by hand and then run "gnulib-tool --import".

Yes.  I'm not sure I would use this interface myself, I probably edit
gnulib-cache.m4 manually.  For me, editing files is simpler than
invoking commands.  Remembering a command name is more difficult than
locating an already existing file.

>> > 2) An option --macro-prefix is introduced, so that the macros exported
>> >    by one gnulib.m4 may be called foo_EARLY, foo_INIT, and the ones in
>> >    another directory bar_EARLY, bar_INIT.
>> >    Also the parameters like module list, avoid list, etc. are stored
>> > outside configure.ac.
>>
>> How about storing the parameters in the per-directory generated
>> Makefile.am?
>
> An interesting idea: Indeed specifications usually go into .am files, not
> .m4 files. But:
>   - The lib/Makefile.am contains stuff that will change by migrating to
>     new versions of gnulib, without changing the parameters. Therefore
>     lib/Makefile.am is a file that should be omitted from CVS. Whereas
>     the parameters belong into CVS. And it's not a good idea to merge
>     the two into a single file, as it would lead to frequent CVS conflicts.
>   - The m4/Makefile.am is considered obsolete since automake-1.9.
>   - Creating a new directory, whose purpose is only to hold a Makefile.am?
>     No.

I don't know if it is a good idea, but maybe it would be possible to
have a gnulib.mk that is included by the auto-generated Makefile.am.
Then gnulib.mk could be stored in CVS, and hold the parameters.  But
this change sounds like work for no apparent gain, if the M4 approach
work.

>> Does this mean LTLIBOBJS will be foo_LTLIBOBJS instead?  That would
>> indeed be good news, I dislike the global nature of AC_REPLACE_FUNCS.
>
> I dislike that too. Currently I have to hack around AC_LIBSOURCES
> and AC_LIBOBJ in order to avoid errors from automake. I'm sure Jim's and
> Paul's change to use AC_LIBSOURCES in *.m4 files will cause problems here
> again.

Yes, if I used any non-gnulib AC_REPLACE_FUNCS in my configure.ac, I
would have a problem with that change.  But I think the real problem
is AC_REPLACE_FUNC/LIBOBJ's rather than this change in gnulib.

Thanks,
Simon