Hi Simon,
> Getting gnulib to build natively on Windows was a bit difficult
I built gnulib on Windows a dozen of times already. The configuration
that works best is from within a cygwin environment, with
PATH=/usr/local/mingw/bin:$PATH
export PATH
./configure --host=i586-pc-mingw32 --prefix=/usr/local/mingw \
CPPFLAGS="-mno-cygwin -Wall -I/usr/local/mingw/include" \
CFLAGS="-mno-cygwin -O2 -g" \
CXXFLAGS="-mno-cygwin -O2 -g" \
LDFLAGS="-mno-cygwin -L/usr/local/mingw/lib"
> "make" appears to break when trying to CreateProcess on /usr/bin/mkdir which
> doesn't exist as a binary.
It is customary on Windows to be able to write a command "foo", and the
spawn* functions will search for foo.bat, foo.cmd, foo.exe, and call
CreateProcess with the resulting command name. If a "make" program calls
CreateProcess directly, without doing this step of searching the right
suffix, that counts as somewhat broken to me.
> How about this patch? It allows users to
> specify the mkdir command when invoking 'make'.
This patch does not fix the problem, and is not in consistent with the
general approach of autoconf.
It does not solve the problem: If @MKDIR_P@ expands to '/usr/bin/mkdir -p'
and you want it - for whatever reason - to expand to '/usr/bin/mkdir.exe -p',
then you need to change the autoconf macro which assigns MKDIR_P.
It is not consistent with the general approach of autoconf: If a building
user wants to override some values of variables determined by autoconf, he
should do that by setting the particular cache variable name while
(re-)running configure, *not* by passing the modified variable values to
'make'. The reasons are:
1) Some variables are substituted into other files than Makefiles.
2) Some other AC_SUBSTed variable values may depend on the guessed ones.
3) When recursing into subdirectories, variables passed on the
command line are not necessarily passed to subdirectory 'make' runs.
(GNU make and BSD make do this, but Solaris make does not.)
Bruno
