bug-gnulib
[Top][All Lists]
Advanced

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

[bug-gnulib] Re: [bug-hello] gnulib and hello


From: Alexandre Duret-Lutz
Subject: [bug-gnulib] Re: [bug-hello] gnulib and hello
Date: Sat, 18 Dec 2004 03:16:19 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

[Added address@hidden for the regex.c issue mentioned below;
I'm not sure where the exit.h/xalloc.h/... error comes from.]

>>> "Karl" == Karl Berry <address@hidden> writes:
[...]
 Karl> The difference is that auto* is an integrated piece of
 Karl> software.  Gnulib is a bunch of little modules, mostly
 Karl> completely independent.

Hmm, you mean like all these little tools gathered into
coreutils, or like all those text files in miscfiles?  <wink>

 Karl> It makes no sense to make a "release" of it.

It would help people without net access.  It would help teams to
use the same version of these files.  It would help to simply
designate versions in which the "mostly completely independent"
modules are known to work together and with the other tools.  It
would not cost anything to people who continue to fetch the
files from CVS.

Right now I cannot bootstrap CVS M4, because it uses the regex
module which mistakenly adds `regex.c' to libgnu_la_SOURCES.
The diagnostic is

gnu/Makefile.am:18: automatically discovered file `regex.c' should not be 
explicitly mentioned

and after fixing this by hand the build later fails with

 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gnu -I../gnu -I.. -I.. -I../libltdl 
-I/home/adl/usr/include -O2 -MT builtin.lo -MD -MP -MF .deps/builtin.Tpo -c 
builtin.c  -fPIC -DPIC -o .libs/builtin.o
In file included from m4module.h:24,
                 from m4private.h:29,
                 from builtin.c:23:
../m4/system.h:45:21: m4/exit.h: No such file or directory
../m4/system.h:46:23: m4/xalloc.h: No such file or directory
../m4/system.h:47:25: m4/xstrndup.h: No such file or directory
make[2]: *** [builtin.lo] Error 1
make[2]: Leaving directory `/home/adl/projs/cvs/m4/m4'

I assume these are files that would normally comes from gnulib
modules.

Undoubtedly the bootstrap script (which calls gnulib-tool
amongst other things, and ignore all exit codes) used to work at
some point in the past.  If there was releases of gnulib, I
could use the release expected by CVS M4 to get a build.  I had
similar problems with Bison some months ago.

Without releases I believe the only safe use of gnulib is the
one we already discussed for Hello: all the files installed by
gnulib-tool should be kept in CVS, and `gnulib-tool' should be
called explicitly from a `make update-gnulib-files' rule, not
from a bootstrap script.  That way you keep yourself away from
temporary breakages in CVS gnulib, and you do not require the
other users of your CVS tree to install gnulib.  (And hopefully
autoreconf works directly on the checked-out tree.)
-- 
Alexandre Duret-Lutz





reply via email to

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