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.
> > 4) ChangeLogs
> >
> > gnulib-tool creates backup files and updates the ChangeLogs, like
> > gettextize does.
>
> Please make it possible to disable this, I have auto-generated
> ChangeLogs through cvs2cl in my projects.
The ChangeLogs can be disabled through --no-changelog. The backup files
cannot be disabled. But you can remove them on your own afterwards.
> > 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".
> > 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.
> 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.
> > The autogen.sh script will then typically contain a single command:
> > (type -f gnulib-tool) > /dev/null 2>&1 && gnulib-tool --import
> > This should simplify 'bison/bootstrap' and 'tar/bootstrap' considerably.
>
> Plus autoreconf -fvi, I assume.
Yes. I meant: the only commands dealing with gnulib-tool in such a script
will fit in a single line.
Bruno
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
