[Top][All Lists]

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

Re: whitespaces in filenames [was: bug in $(wildcard) on Windows?]

From: Paul D. Smith
Subject: Re: whitespaces in filenames [was: bug in $(wildcard) on Windows?]
Date: Fri, 18 Mar 2005 08:54:32 -0500

%% Fabio Alemagna <address@hidden> writes:

  fa> Couldn't it be done so that instead of using spaces, as word
  fa> delimiters, make used NUL chars?

No, because NUL characters delimit the end of strings.  You must
understand that make is just a string manipulator.  It doesn't really
have a separate category of "file names", or "options", or anything
else.  It just has a bunch of strings.  At certain times during
processing of the makefile, those strings are interpreted to mean "names
of targets", and names of targets are sometimes the same as names of
files.  But internally to make, EVERYTHING is stored as just a normal,
NUL-delimited string.

  fa> Is there anything that doesn't wouldn't make this a viable option? 

My idea for handling spaces (and colons, and even "$", which are also
problematic in filenames) is something like this:

  * There would be a UTF-8 special character (not NUL) chosen to
    represent each special character.  Say, SPC = 0x01, : = 0x02, $ =
    0x03, etc.

    These values would be stored in their translated state internally to

  * Functions that managed filenames would automatically encode them: so
    the return from $(wildcard ...), for example, would be "correct".

  * A new method for encoding strings would need to be found.  Maybe
    something like $[...] where "..." would be encoded.  This part is
    tricky and needs to be considered carefully.

  * Whenever make wanted to send those strings anywhere, either print
    them or send them to a command to run, etc. it would first
    un-translate the strings.  Again, it's tricky to make sure that this
    happened everywhere necessary.

Because whitespace is still a delimiter and NUL characters are still end
of string markers, this method has the advantage of not requiring
changes throughout make: it can just change things at the input and

There is a huge amount of work to get this to happen, though, and the
interface for the encoding needs to be thought out.

 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]