Hi all. I spent a bit of time this weekend looking into what it would take to update GNU make to use the glob/fnmatch implementations from the current gnulib, rather than the ancient (and buggy) implementation that GNU make has embedded, more or less unchanged, for at least 25 years.
This, unfortunately, turns out to be quite a daunting task. Gnulib glob/fnmatch rely on a huge number of other gnulib packages so instead of the simple two-file implementation GNU make has now it expands to a lib directory containing 20+ files (I didn't actually count but it's quite a lot). This matters for a few reasons: first, GNU make provides a bootstrapping script that will let you compile make on systems which don't already have make... that means that I need to be able to build all these extra files without the assistance of automake (I do run configure). I'm not sure how easy that will be. More worrying, GNU make is compile-able on Windows and does not require Cygwin: it can be built using native MSVC and/or MingW32. For bootstrapping GNU make provides a "build_w32.bat" file that compiles make using either gcc or MSVC. In this setup I have a hard-coded config.h for Windows that I install since I don't run configure. Making this work with the many packages added to lib seems complex. Finally, GNU make can also be compiled on other less common architectures, such as VMS and these ports are quite active. Is there any information about all these different glob/fnmatch requirements in gnulib, insofar as portability to other environments like VMS? I would really like to use native gnulib implementations but the overhead involved has me considering whether it would be feasible to try to extract the latest implementation and somehow fencing it in to avoid all these extra dependencies. Any comments anyone has would be welcome, cheers!
