Hi Jan, > 2011-02-25 Jan Nieuwenhuizen <jann...@gnu.org> > > * tests/macros.h (GL_RM_RF): New macro: fallback for `rm -rf'. > * tests/test-*.c: Use it.
I have three objections against this patch: 1) It goes against an important design principle of gnulib, which is: Try to write the code as you would for a fully POSIX compliant system. Concentrate the workarounds in a single place. Here it would mean to write a system() emulation that recognizes the 'rm' command, rather than to change 32 files that use system(). 2) As said in <http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00012.html>: The recommended environment for mingw is to use cygwin as a host environment and "cross" compile using a configuration like this: PATH=/usr/local/mingw/bin:$PATH export PATH ./configure --host=i586-pc-mingw32 --prefix=/usr/local/mingw \ CC="gcc-3 -mno-cygwin" \ CXX="g++-3 -mno-cygwin" \ CPPFLAGS="-Wall -I/usr/local/mingw/include" \ LDFLAGS="-L/usr/local/mingw/lib" A less recommendable environment for mingw is MSYS. Here you don't even need to specify --host. In both cases, the environment is assumed to contain a bash and the coreutils. Therefore an 'rm' command will be found in PATH. Given that there are these two setups which don't require patching the unit tests, what's the point in using an environment which has no 'rm' command? 3) Gnulib relies on a configure file being created by Autoconf, and such configure files use 'rm' and other basic coreutils programs in many places. Also, Gnulib relies on a Makefile, produced by Automake and Autoconf, and to execute a Makefile, you need 'make', 'sh', and again the basic coreutils programs. It is not clear to me how you can use _any_ part of Gnulib without having an 'rm' program accessible through PATH. And even if you can do so, is it not simple enough to install either Cygwin, or MSYS, or the gnuwin32 project's binaries? Bruno -- In memoriam Stephan Brassloff <http://de.wikipedia.org/wiki/Stephan_Brassloff>
