I cannot reproduce this locally, hence my bug report is rather devoid of details. However, it's 100% reproducible in Koji (the Fedora Rawhide build system) on *all* architectures except armv7: FAIL:
So the above was the clue to fixing it. Because I'm using -C, ‘config.cache’ was caching the results of a previous locale command. In the upgrade from F28->29 the locales were uninstalled and the
I'm using gnulib 6ccfbb4ce5d4fa79f7afb48f3648f2e0401523c3 from a few days ago. After upgrading to Fedora 29, the glibc-langpack-fr locale is no longer installed by default. This causes many tests to
Hi Paul, OK. No, I was only commenting on your statement "An alternative would be to use ifdef WINDOWS32 ...". The patch was fine. Maybe in general in GNU. But not in gnulib. Because in gnulib it's e
Yes, given that the uses of 'sed' in gnulib are nearly all of the form sed -e 's/@VAR1@/VALUE1/g' ... -e 's/@VARn@/VALUEn/g' FILE you could write a program 'atsubst' such that atsubst VAR1 VALUE1 ...
Ah, thanks for clarifications. MS-DOS has glob and fnmatch in its library, so it probably doesn't need those from Gnulib. "MS-DOS" is a misnomer in this case: it really means the DJGPP tools (www.de
This sounds like a good compromise between Paul's requirements and the wish to have little manual work. When you implement it, take a look at the gnulib-tool options: --avoid to avoid a module despit
But we don't have two gnulibs: one with many features, and a separate one with as few HAVE_* symbols as possible. However, gnulib modules can add new HAVE_* symbols and configuration tests at any mom
Sorry for not being clear: I meant 5 replacement header files that contain @-tokens, not 5 supported target systems. The systems we ostensibly support are POSIX/UNIX, Windows, VMS, MS-DOS (?), and Am
For the record: what are those 5 systems? MS-Windows is one, but what are the others? Here's an (100% untested) idea: . We ignore all the Gnulib headers that work around problems in standard headers
I'm not sure. Make is not like any other GNU package, because it is one of the basic tools required to build other tools. IOW, building Make could be part of bootstrapping a GNU environment on a pla
Hi Paul, Using a script to compile the various .c files files in turn is easy. The problem is to maintain the config.h file, if you don't want to assume a configure-capable system. What are the reaso
If you have a configure-capable system, use autotools to compile GNU make. If you don't have a configure-capable system, use the provided bootstrap script (or create your own) to build GNU make. Such
Unfortunately (perhaps only for me) this isn't sufficient. GNU make is a foundational tool: you need it before you can build any other package. It is also widely used by itself in environments where
The VMS people apparently actually achieved this task; the binaries of these tools are for download at https://sourceforge.net/projects/gnv/ . So, the same approach as for porting to native Windows s
I think you are barking up the wrong tree. In the other mail I've explained how you can reduce the number of build systems you use from 3 (Autoconf+Automake, Windows nmake, VMS nms) to one (Autoconf+
Paul Smith wrote in <https://lists.gnu.org/archive/html/bug-gnulib/2018-04/msg00038.html>: To cope for this case, I would suggest to generate a "build all at once" script from the generated Makefiles
On 05/15/2018 03:31 PM, Paul Smith wrote: 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 c
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 repla
Hello Matteo and all, Let me emphasize that I'm not against this feature, but I just think it should be disabled by default, and enabled explicitly with a "configure" flag when downstream users want