bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib-tool changes


From: Simon Josefsson
Subject: Re: gnulib-tool changes
Date: Wed, 31 Aug 2005 14:26:04 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Bruno Haible <address@hidden> writes:

> 2) Support for multiple gnulib directories with a single configure.ac.
>
> It happens that a project wants to use gnulib in different parts, sometimes
> even with different licenses, but these parts share the same config.h and
> therefore the same configure.ac. (It is quite hard to work with different
> config.h's in different subdirectories.)

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.  I look
forward to your fixes.

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

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

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

Does this mean LTLIBOBJS will be foo_LTLIBOBJS instead?  That would
indeed be good news, I dislike the global nature of AC_REPLACE_FUNCS.

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

Thanks,
Simon




reply via email to

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