Eli Zaretskii wrote: > > This is the downside of the many features gnulib has: > > - C++ support, > > - support for many platforms, > > - using the function name 'rpl_foo' if and only if 'foo' would collide > > with system-provided 'foo'. > > The downside is that wrong guesses for the HAVE_* symbols lead to > > compilation failures more quickly.) > > All this is true, but Paul is concerned only by a few specific > platforms, and about a single programming language. So the above > features are mostly irrelevant in the case in point.
But we don't have two gnulibs: one with many features, and a separate one with as few HAVE_* symbols as possible. > > Really, the approach of maintaining a config.h for a particular platform > > by hand is outdated. > > Nevertheless, GNU Make uses it to this day. However, gnulib modules can add new HAVE_* symbols and configuration tests at any moment, and without notice in the NEWS file. If Paul is OK to update (or let his porters update) the config.h files for native Windows, VMS, and so on, each time he upgrades to a newer version of gnulib, then fine. If not, he either shouldn't use gnulib, or he should change the way he works with config.h. Bruno
