On 2007-05-18 12:59Z, Earnie Boyd wrote: > Quoting Eli Zaretskii <[EMAIL PROTECTED]>: [...] >> Btw, would using a function work here? Something like this: >> >> include $(SOURCE_ROOT)/$(file "Main Line")/default.mk >> >> where the hypothetical function $file just returns its argument. >> Would this work? > > I think it might assuming the function $file returned the 8.3 version of > the name.
Might this provide the optimal answer to the recurring questions about paths with embedded blanks? $(dospath name...) Return an alias for file 'name'. On systems that encourage embedding blanks in paths, and provide an alias with no blanks, return that alias if available; otherwise, return the argument. All characters in 'name' are treated as part of a single argument, so this function can even accommodate a name like "a, b, c". Users who really want to use paths with blanks often try quoting, then find that quoting solves few of the problems. Would a builtin function like this solve most of the problems? It's unnatural, but perhaps no less unnatural than necessary. Here's a classic example: # This doesn't work as hoped. VPATH = My Source Files # Quoting doesn't help. VPATH = "My Source Files" # But wouldn't this work? VPATH = $(dospath My Source Files, version X) # It would expand to something like this: VPATH = My~7 I can think of at least one problem it might not solve. Suppose a dependency file is created in '/build~2' and refers to '/src~3/a.c'. If new directories like 'build my stuff #6' and 'src 3.x' are later created, then AIUI that might cause the original "short" names to change, invalidating the dependency files. Perhaps there are similar problematic scenarios with makefiles that create and destroy directories whose names have embedded spaces. Still, if the issues are finite and can be described, would such a builtin function be worth adding? _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
