make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: variables with spaces


From: Paul D. Smith
Subject: Re: variables with spaces
Date: Mon, 31 Mar 2003 13:50:49 -0500

%% "Eli Zaretskii" <address@hidden> writes:

  ez> How about adding to Make some way of using whitespace in a file
  ez> name?  Perhaps we could have something like $w{} that would expand
  ez> into a a space?

The most difficult problem is that expansion happens all the time, so
you can't use a simple variable.  If you did, the code would have to be
modified to understand it and not expand it under "normal" situations.
Then there would be a special expansion that would happen after the
normal expansion for a command script and before the command script was
provided to the shell for processing, that would replace that token with
a space.  This would have to be done _anywhere_ that the text could be
printed, so in debugging statements, $(error ...)  and $(warn ...)
output, -p output, printing of command scripts, etc. etc.

The second problem is how do you get the tokens into the filenames?  If
it's a text token like you show above then makefiles could contain it
(users could type it in).  But we'd also have to modify things like
$(wildcard ...) and the results of globbing to return the right thing.


For a while I was toying with an idea like this: a special syntax which
"encoded" a string as a single "word" for the purposes of make.  So,
you'd say something like:

  foo: $[file with whitespace]

and "file with whitespace" would be treated as one word, for the
purposes of make parsing.  Likewise, the results of the $(wildcard ...)
function would be a list of these "encoded" words.

Then the question becomes how to encode them?  I was playing with the
idea of replacing space characters with some control character, like
ASCII 0x01 or something.  Then none of the make parsing functions would
treat it like whitespace, and we'd just have to translate it back again
before printing it.  It also has the advantage that the string is the
same length before and after encoding/decoding.

Then I realized that make support multiple locales and some of the
charsets people might use to write makefiles in might use control chars
like 0x01.  I'm not very familiar with that so I can't say whether it
would be true or not... Eli, you probably are much more able than I to
talk about whether this is viable or not.

-- 
-------------------------------------------------------------------------------
 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]