On Fri, 2018-04-13 at 10:42 +0300, Eli Zaretskii wrote: > > This might require changing Gnulib to make it easier to decouple its > > glob.c and fnmatch.c from the rest of Gnulib. We've done that for > > some of the Gnulib modules that Emacs uses, and I expect we could do > > that for glob.c and fnmatch.c too. > > I didn't realize such an option was on the table. If that's > possible, it is certainly a much better way forward.
As a starting position I've modified the GNU make repository to change the "src/glob" directory to be a top-level "lib" directory, and I've imported alloca and getloadavg modules from gnulib to replace the old versions previously provided with GNU make. Things mostly still work even on Windows, with one small change to getloadavg that I'll send under separate cover. glob/fnmatch is a different story and I'm not sure quite how to tackle it yet. So far I've just moved the original glob/fnmatch (old and buggy) into lib/ to keep things working. Here's what I find extremely difficult to manage regarding gnulib's current design: - Heavy reliance on .in files that need to be transformed. On systems that aren't POSIX and don't have ready access to sed or similar tools, this is very annoying to deal with. The original design of autoconf, where there was a single config.h which defined a ton of #define values that were then tested by other files, was far simpler for non-traditional systems: you merely had to create a pre-defined config.h file for such a target (most of the time these targets were homogeneous enough across releases that they didn't require autoconf anyway) and arrange to have the file renamed to start the build process. However with gnulib's current design for the replacement system headers (at least) instead of using the old-style '#if !HAVE_BOOL' (as on example from stdbool.in.h), they use: # if !@HAVE__BOOL@ This means I can't just define HAVE_BOOL in config.h and then use this header file, I need to come up with some way of emulating sed behavior on all my supported platforms (Windows, VMS, etc.) so I can replace these values. Or else I have to create per-system instances of each of these files, of which I already have 5 just for alloca and getloadavg and if I do take on glob/fnmatch that number will balloon. For glob.in.h in gnulib it's even worse; even the header guards require replacement!! #ifndef _@GUARD_PREFIX@_GLOB_H I understand that the goal is to have versions of these standard header files which can be used without config.h, but the GNU coding standards suggest that config.h must be included first in each compilation unit, before even system headers, so to me that desire doesn't outweigh the downside of using this method for non-traditional systems. I'm interested in anyone's opinion on how best to deal with this issue. Cheers!
