On Fri, 2007-05-18 at 18:22 +0300, Eli Zaretskii wrote: > > Date: Fri, 18 May 2007 14:33:37 +0000 > > From: Greg Chicares <[EMAIL PROTECTED]> > > > > 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". > > Yikes! I'd prefer a general solution that would work on other > platforms as well, not only on DOS/Windows. After all, file names > with blanks find their way into Posix platforms also.
This is true: I don't want a special platform-specific solution to this problem. However, solving the case of include is actually a fairly simple example of the complete problem. Providing a generally useful way for make to handle filenames containing whitespace (and other characters special to make, such as colons) requires a lot more effort. At least in include you know that the arguments are supposed to be filenames. How can you determine what's a filename or not in a command script, or in a make function? I've given this problem some thought in the past, and my idea is to have a special way to tell make that a string of characters is supposed to be treated as "a word", for all purposes that make uses "words" today; that includes a target or prerequisite name, splitting up strings for use with make functions, etc. For characters within a word that make treats specially, such as spaces, tabs, colons, and even dollar signs, make would translate into some token internally. I think it's important that this token be only one character long, since increasing the sizes of strings will lead to other complications. Thus, all functions, parsing, etc. on a string would proceed as they do now. Whenever make was going to externalize these "words", either to print them out to the user or to send them to a subshell to run a command, it would translate the tokens back into their respective characters. What I've thought about is using low ASCII values for these tokens. This would still allow makefiles to be written in UTF-8, with the exception of some special characters. We would need to look at the possible characters and choose the ones we want carefully (probably after talking to folks who know how these characters are used), but I think we should be able to find enough characters that aren't needed otherwise. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32