Thanks for your answer. I have followed your advice to *not* install neither MinGW nor Msys in a path containing spaces (and everything went well). However, this is not a long term answer, as it seems to me difficult to state that autotools forbid the use of paths with spaces.
The solution I had behind my head (which is somewhat different from yours) would be to write a small program (call it eval_progname) which interface is similar to 'time', namely that takes a progname and a list of arguments usually passed to the shell for evaluation and execution. 'eval_progname' will take its first argument (which will be the "$LD" for example, quotes are important here) and try to find the location of the first space which preceeding path would lead to a valid executable (with the help of PATH environment variable for relative paths); then it will restore the actual progname as the actual one to be executed, and the rest of the first argument as actual arguments preceeding the original arguments. It finally will 'exec' the computed progname with computed arguments. Of course, such a program could be escaped with "eval" for people who knows that there is no space in their paths (and for evaluation without 'eval_progname'), and it should not break any backward compatibility in the rest of autotools code. I guess that it could also be written as a shell function, but I think that an executable should be much more efficient.
IMHO, this should bring a solution to the problem of execution, but not for variable evaluation. But I guess that autotools already should handle carefully spaces in variable evaluation, and if they don't, then they should be fixed directly.
Your comments are welcome, as I intend to validate that this solution works for autotools (this is rather easy with a Windows system and MinGW).
Thanks for your comments,
Eric
Ralf Wildenhues wrote:
Hi Eric, * Eric PAIRE wrote on Mon, Aug 29, 2005 at 03:31:06PM CEST:I am currently using 'configure' generated file under MinGW. On Windows, Msys and MinGW have been installed in 'Program Files' (Yes, there is an*snip*The 'gcc -print-prog-name-ld' command in AC_PROG_LD returns a complete Windows path which contains a space, then the execution of $LD in AC_PROG_LD_GNU fails, and my LD is not detected as a GNU ld, which has some unwanted consequences...I can imagine..*snip*I would like to get your comments on that, and particularly if paths with spaces in them are supported, or if it is not tested, or if this should be forbidden. In the later case, I guess that this should be clearly stated somewhere (and if it is, I have not been able to find it, sorry).I can give you an unofficial statement: It's a mess. It might work in some cases, but in most it'll break eventually. Autotools started thinking about path names with spaces only very much in an afterthought, long after they were established. One reason is because on classic unixy systems, they are very rarely used. Another is the very common use of white space as command line separator by the common unix shells. Recently, a patch has been posted to make Libtool be able to use spaces in their path names in many places (not the one you're seeing, I believe). I hated the fact that I had to reject it because it breaks compatibility. I've been thinking ever since how we could introduce spaces in variables which contain file lists. In fact, I'm still convinced that it *can* be made to work. It's just a huge amount of work to do it right, and pretty tricky at times[1]. If anyone wants to work on this for Libtool-3.0 (sic), I'm happy to discuss possible plans that would not break compatibility with every other version and autotool we have. For now, though, it's by far easier if you did not use paths with spaces, or some sort of symlinking mechanism to work around them. Cheers, and sorry, Ralf [1] one trick would be to use TAB as list separator and juggle with IFS .. would make for *really* unreadable code..
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
