Re: Environment variables in makefiles with DOS

[Paul Smith]

On Fri, 2007-05-18 at 18:22 +0300, Eli Zaretskii wrote: 
> > Date: Fri, 18 May 2007 14:33:37 +0000
> > From: Greg Chicares <address@hidden>
> > 
> > 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 <address@hidden>          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