Thanks - great.
I've applied most of the first patch. In particular, the point of not polluting the environment was very good - thanks ! I didn't apply some details - mostly saving in config.make the path to chown or cygpath ... here is some explanations of why I thought I would omit those. about chown, my idea is - the configure test checks that a chown is available on the system. This is meant so that people installing for example on some unix emulation environment know they have to install a chown-like tool we use the variable CHOWN rather than hardcoding `chown' in commands so that if you have more than one chown on your system, you can tell gnustep-make to use another one by running 'CHOWN=/opt/nicola/bin/chown make' but we don't want to hardcode the path to the chown we find during configure to the CHOWN variable because we want to make sure that you can change the chown you use after you have configured gnustep-make, and you don't have to reconfigure. For example, if you are using the system chown when you configure gnustep-make but switch to another one later on (say by installing new unix tools in /opt/test/bin, then putting that at the beginning of PATH), we want gnustep-make to use the new one without having you to reconfigure it. about cygpath, I'm not the author of that code, but I think the idea is that you might want to install cygpath.exe, then remove it later on and have it silently and automatically replaced by gnustep-make's cygpath.sh ... not sure but I suppose if the code to detect cygpath is in GNUstep.sh and not in configure.in it's because you want it to be able to detect the available one at runtime. (maybe instead you're right). But I much appreciated some tricks in the first patch, thanks :-) and I applied most of it. > The second patch (which can be applied after the first one) tries to > provide additional robustness. It corrects problems with filenames and > paths that contain whitespace. Several scripts have problems with > quoting. This patch corrects some, but probably there are more. I did start to change gnustep-make to support this but ... it's not enough to support paths containing whitespaces ... I got into two major problems - first is that using an application which is in a directory with a space in the path, and which has a name which contains a space :-) bash seems to have a bug in which it can't run the application from a script. - second is that I played with a configuration in which you configure gnustep-make by using ./configure --prefix="/opt/GNU step" that makes sure all gnustep paths have a space in it ... and well that won't work even after the changes to gnustep-make because the line include $(GNUSTEP_MAKEFILES)/common.make in the user makefiles will expand to include /opt/GNU step/System/Makefiles/common.make which will not work :-) If it were in my/system makefiles, I could easily fix it by using empty:= space:= $(empty) $(empty) include $(subst $(space),\ ,$(GNUSTEP_MAKEFILES)/common.make) but it's in the user makefiles, over which I have no control! Need to think about this, but probably it's a basic problem in make which is not really designed to handle paths and filenames containing spaces ... most make stuff separates filenames by using whitespaces, and I don't know a way to `quote' a filename in the same way as you do in the shell to allow a filename to contain a space. The 'make' authors/designers didn't probably think you could have paths/filenames containing whitespaces. I'll probably apply patches to quote most shell paths in next days ... even if it won't be enough to really support paths/filenames containing whitespaces in it, it's a start. :-) > As far as I can tell GNUstep make currently does not support compilation > in other directories than the source directory. (Using VPATH like > automake does.) Am I mistaken? It can be useful to have a read-only > source tree and a separate build directory. Are there any plans to > support this? (I'm not sure how much work it would be.) Yes - you are correct - gnustep-make does not support this currently. It might or might not be difficult to add it, depends on how we want to add it. I've already some ideas, but I'd like to check how automake does it before trying. _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
