Re: recent gnulib changes require coreutils adaptations
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> However, I can't reproduce that: >> >> $ git clone git://git.sv.gnu.org/coreutils.git cu \ >> && cd cu && ./bootstrap --gnulib-srcdir=/gnulib >> ... >> Creating ./._bootmp/lib/uniwidth/.gitignore >> ... >> ./bootstrap: done. Now you can run './configure'. >> >> Are you sure your copy of coreutils was up to date? > > Yes, I just now checked again; please see the transcript below. > I notice that you bootstrapped from a private copy of gnulib; perhaps > that's out of date on your host? No. I reran the following in a brand-new account on my system, as well as on another system altogether (that claims to be Debian 4.0), just to be sure: $ git clone git://git.sv.gnu.org/coreutils.git cu && cd cu && ./bootstrap Both times, it succeeded. However, the log showed differences from yours. Your log has the following "overrides" lines, while mine don't: > 505-penguin $ git clone git://git.sv.gnu.org/coreutils.git cu ... > ./bootstrap: build-aux/.gitignore overrides ._bootmp/build-aux/.gitignore ... > ./bootstrap: doc/.gitignore overrides ._bootmp/doc/.gitignore ... > ./bootstrap: lib/.gitignore overrides ._bootmp/lib/.gitignore That probably comes down to the use of version_controlled_file() in bootstrap's slurp function, and makes me wonder if our differences are due to your using a version of git for which "git-rm -n file" doesn't do what version_controlled_file expects it to. I've tested the following versions of git: 1.5.3.rc1.27.ga5e40 1.5.2.4 1.4.4.4 E.g., from a git-cloned coreutils work area, "git-rm -n doc/.gitignore" should exit successfully. Does that work for you?
Reliance on
Hi, I just noticed that Gnulib modules rely on the availability of a `#include'able file. I'm using Gnulib in a project that does: AC_CONFIG_HEADER([some-special-name.h]) There, Gnulib modules fail to compile because is not available. I'd happily work around this by doing something like: AC_CONFIG_HEADERS([some-special-name.h lib/config.h]) but then `autoheader' does not generate `lib/config.h.in', which is a pain. Any hint? Thanks, Ludovic.
Re: Reliance on
Hello Ludovic, * Ludovic Courtès wrote on Tue, Jul 17, 2007 at 05:58:34PM CEST: > > AC_CONFIG_HEADERS([some-special-name.h lib/config.h]) > > but then `autoheader' does not generate `lib/config.h.in', which is a > pain. You could either write lib/config.h.in yourself; it could contain #include "some-special-name.h" (also, you could just use a file lib/config.h -- there are no #defines that are changed by configure). Another possibility is to generate lib/config.h.in from some-special-name.h.in, say, by some sed script or an autoheader invocation with arguments and output redirection. (I suppose another gnulib-specific possibility is that someone hacks gnulib-tool to support arbitrary other configuration header file names; or to undo the decision that was made last year to assume a config.h header file.) Hope that helps. Cheers, Ralf
POTFILES.in updates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since the use of gnulib has the tendency to introduce translatable strings into a project, should there be a way for gnulib-tool to mark which files need to be added to POTFILES.in? Perhaps a new entry in each module description that calls out any files with translatable strings? I noticed, for example, that findutils was missing a number of strings from its .pot file: http://www.nabble.com/.pot-files-update-tf4101032.html#a11662271 - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnZdd84KuGfSFAYARAmwaAJ41kQG9B+xdlK8Jzsv9lV1qNY3WagCfYXmd 79G2xnKzzJKsPZfM0qsc2uI= =BmJB -END PGP SIGNATURE-
Re: Reliance on
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 7/17/2007 4:40 PM: > > (I suppose another gnulib-specific possibility is that someone hacks > gnulib-tool to support arbitrary other configuration header file names; > or to undo the decision that was made last year to assume a config.h > header file.) One of the reasons that gnulib moved towards assuming is that it makes for shorter command lines in make output, and it is easier to write maintainer-check rules that ensure every .c includes as the first line (a necessity if gnulib replaces any system header). In the early days of autoconf, it was sufficient to just list lots of -D... options on the command line, but these days, gnulib defines so many macros that it is feasible to exceed command line limits on some platforms if you do not lump them all into a config.h. I think it will be easier for you to provide a stub lib/config.h than to try and restore all the sed invocations into gnulib-tool to convert to your custom name at checkout, not to mention that gnulib-tool is already slow enough as it is. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnZkI84KuGfSFAYARAlLjAJ9xrUo62IjJe90dR+Ai5AyLDrZSXQCgzTOZ 3WZbnO04H1hyH9fUBH2T49w= =iCtU -END PGP SIGNATURE-
