Re: gnulib without autoconf?
Ben Walton wrote: > I'm wondering whether its feasible to use gnulib in a project that > doesn't use autoconf/automake? Gnulib depends heavily on autoconf and automake. You could manually extract the portions you think you need and attempt to use them without the requisite glue, but that is very error-prone. > Would it be easier to first auto* the > project and then add gnulib? Yes.
Re: gnulib-tool feature request
Sam Steingold writes: > On 2/26/10, Simon Josefsson wrote: >> Sam Steingold writes: >> >> > Since I use gnulib in several sub-modules, I need to avoid conflicts >> > between different gnulib imports. >> > thus I need to make all those _GL_* constants module-specific. >> > thus I need gnulib-tool to accept a --macro-prefix option and this patch: >> >> >> I believe the recommended way to avoid conflicts between different >> gnulib imports is to use a separate configure.ac for each gnulib import, > > of course I have a separate configure.in for each module! > the setup works just fine, I just don't want to have to apply the > patch to gnulib-too myself each time I pull from gnulib. Then I don't understand what purpose the patch serves? Each configure.in instance should have its own namespace? /Simon
Re: gnulib without autoconf?
Excerpts from Jim Meyering's message of Sat Feb 27 03:15:59 -0500 2010: > > Would it be easier to first auto* the project and then add gnulib? > > Yes. Ok, that's what I thought. Thanks for the confirmation. -Ben signature.asc Description: PGP signature
empty gnulib git repository
Hello, what's happened to the git repository? This is what I get when I try to clone it: $ git clone git://git.sv.gnu.org/gnulib.git Initialized empty Git repository in /tmp/gnulib/.git/ warning: You appear to have cloned an empty repository. and on the http://git.savannah.gnu.org/cgit/gnulib.git web page I see this message: "Repository seems to be empty" Thanks, Giuseppe
Re: [Savannah-hackers-public] empty gnulib git repository
Giuseppe Scrivano wrote: > what's happened to the git repository? > > This is what I get when I try to clone it: > > $ git clone git://git.sv.gnu.org/gnulib.git > Initialized empty Git repository in /tmp/gnulib/.git/ > warning: You appear to have cloned an empty repository. > > and on the http://git.savannah.gnu.org/cgit/gnulib.git web page I see > this message: > > "Repository seems to be empty" I did that. It's merely a permissions problem. Fixing now. Will explain shortly.
Re: [Savannah-hackers-public] empty gnulib git repository
Giuseppe Scrivano wrote: > what's happened to the git repository? > > This is what I get when I try to clone it: > > $ git clone git://git.sv.gnu.org/gnulib.git > Initialized empty Git repository in /tmp/gnulib/.git/ > warning: You appear to have cloned an empty repository. Sorry about that, and thanks for reporting it. An hour or two ago, I noticed that the repository was getting a bit bloated, so ran "git gc" as root on the server. Unfortunately, my umask was 077, which resulted in the pack-related files being created world-unreadable. I've just fixed it manually.
Re: [PATCH] lib/malloca.c, lib/md5.c, lib/sha1.c: don't include unless HAVE_CONFIG_H is defined
Hi Eric, > [Gnulib] uses so many #defines that it would exceed command-line > length limits on some platforms if they were passed via -D through > the Makefile. That, and some things don't work well through > makefiles, such as an expansion containing # (and gnulib now has some > of those for the *.in.h replacement headers). So going without any > header at all is no longer a portable option. you are right. For projects of non-trivial size, config.h is clearly the way to go. In my particular case, however, the situation is different. The only Gnulib module I'm interested in is MD5. At first, I assumed that I'd need SHA1, too, but then it turned out that I don't. Anyway, I just need a single Gnulib module and the number of Autoconf defines involved in that build is fairly small. There is no technical reason for that project to have a config.h header. It works just perfectly without one. Now, I completely agree that Gnulib shouldn't try to support non-config.h builds in general. It's not worth the effort, really. Yet, at the same time it would feel like prudent software engineering if Gnulib would avoid creating unnecessary obstacles for those projects that work fine without config.h. I see no compelling technical reason to include config.h in Gnulib code without the proper include guards. Neither do I see a strong technical reason to refuse my patch, which remedies the situation for the MD5 and SHA1 module. Anyway, this is no big deal. All things considered, I'll probably just modify my project to use config.h. Thank you for your consideration. Take care, Peter
