On Mon, 29 Dec 2014 16:27:51 -0800, Kip Warner said: > My configure.ac updates CXXFLAGS periodically during execution, such as > via pkg-config. Some of the include paths returned from pkg-config's > --cflags contain spaces which I require. ... Bob Friesenhahn said: > The solution is to assure that all paths used do not include spaces. Kip Warner said: > Unfortunately I need spaces on GNU systems and possibly elsewhere. I think "don't have spaces in paths" is increasingly impractical advice. Mac OS X and Windows systems (msys, cygwin) *normally* have directory names with spaces, and these names *are* the correct probe results. Autoconf is intended to be "a tool for producing shell scripts that automatically configure software source code packages to adapt to many kinds of Posix-like systems... The configuration scripts produced by Autoconf require no manual user intervention when run". But this is *NOT* true for the large number of systems where spaces occur in directory names, and users cannot control this; they expect a tool like autoconf to handle it. The fundamental problem is that space has *TWO* conflicting meanings in autoconf: 1. Part of a path name. 2. Separator between arguments (including options) It's reasonable to tell developers "do not put spaces in your source code filenames", but users generally can't prevent spaces from being in the directory names in their environment. I propose developing and documenting a standard convention for spaces in pathnames that focuses on making things easier for *users* - the builders of the software. This convention could be enabled by some statement in autoconf.ac, and perhaps it could be enabled by default some time in the future. If autoconf defined a simple convention for differentiating spaces in pathnames from spaces in argument separators, it might "just work". It'd be tricky to find such a convention, but if one can be found, autoconf would be able to adapt to many common systems. I propose the following convention, as a first cut: 1. Unquoted spaces continue to mean "argument separator". This is by far the most common use of spaces today, so making that the default meaning seems sensible. 2. Pathnames with spaces must use double-quotes in a way that enclose the spaces (if they're passed in as configuration values or provided as probe results). Any automatic search for a program (e.g., AC_CHECK_PROG and AC_CHECK_PROGS) that found a pathname with spaces would surround the pathname using double-quotes, but it would *not* surround the first few characters - instead, it could insert a double-quote after the path separator that first *began* a component with spaces. Since an automatically-generated pathname won't begin with double-quotes, current scripts that look for "absolute pathnames" by looking for "/" or "C:" at the beginning would keep working. It'd be possible to use "\" in front of each space instead, but since variables go through multiple processing steps through different tools, and "\" is a pathname separator on Windows, I expect that backslash would be less robust than double-quotes. The idea would be that generated Makefiles (for example) could look like this: SBCL = /cygdrive/c/"Program Files/Steel Bank Common Lisp/1.2.6/sbcl" EGREP = /usr/bin/grep -E ... something.dest: something.src $(EGREP) ... $(SBCL) ... I think this would require a relatively minor change in AC_CHECK_PROG, and the result would be much better automation on many systems. This is a slightly tricky problem; comments welcome. It'd be nice to see a simple and relatively clean solution to the problem. I think "use double-quotes when pathnames contain spaces" is a plausible answer. --- David A. Wheeler _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
