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
