I wrote: > > SBCL =/cygdrive/c/"Program Files/Steel Bank Common Lisp/1.2.6/sbcl" On Tue, 30 Dec 2014 23:38:20 -0800, Paul Eggert <eggert@xxxxxxxxxxx> replied: > That wouldn't work for commands that do stuff like this: > $(MAKE) SBCL="$(SBCL)" Sure, but this minor variation WOULD work in a makefile, and it's an easy fix: $(MAKE) SBCL='$(SBCL)' You can also embed double-quotes when setting environment variables and invoking make directly: ENV_SBCL='/cygdrive/c/"Program Files/Steel Bank Common Lisp/1.2.6/sbcl"' make demo3 Another possible option (noted below) is to use single quotes instead of double quotes. Maybe that would be the "easiest way forward". > There is no simple and clean solution to this problem, I'm afraid. That may be true, but maybe we can find "simple and clean enough". There are really only 3 main options that I see to disambiguate "spaces used as argument separators" and "spaces in pathnames" in input: 1. backslash prefixing (but this is heavily overloaded because this data goes a varying number of unquoting processes), 2. double quotes 3. single quotes > The best place to start fixing it would be with GNU Make... But that only works with GNU make. GNU make is great, but it's not the only make. Autoconf (and automake) are supposed to work with other makes, so any solution needs to *NOT* depend on GNU make. > In the meantime, people will just have to live with not having > white space in their development sources' directory names. The problem is that that's not the problem :-). I agree that developers should avoid having whitespace in their source dirnames; typically this is easy to do. The problem is that in many *USER* (builder) environments, tools and configuration information have pathnames with spaces. This is NOT the developer's environment at all, and thus the developer CANNOT control this. Users can't control it either, actually; it is a current fact of their environment, especially if they use Mac OS X or Windows, and not something they can change. They can do workarounds with symlinks, etc., to try to *hide* the reality, but since autoconf is supposed to do things *automatically*, that means that autoconf fails to do the one job it's supposed to do: automatic configuration. --- David A. Wheeler _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
