bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib-tool changes


From: Bruno Haible
Subject: Re: gnulib-tool changes
Date: Wed, 31 Aug 2005 16:33:56 +0200
User-agent: KMail/1.5

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]