Re: [PATCH] lib/malloca.c, lib/md5.c, lib/sha1.c: don't include <config.h> unless HAVE_CONFIG_H is defined

[Peter Simons]

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