Re: make cannot handle prerequisites that contain a colon

[Markus Kuhn]

"Paul D. Smith" wrote on 2004-10-18 00:26 UTC:
> %% Markus Kuhn <address@hidden> writes:
> 
>   mk> The GNU make 3.80 manual lacks a section on quoting of special
>   mk> characters that describes how any arbitrary byte sequence can be
>   mk> provided as a prerequisite or a target in a rule.
> 
> There is no way to do this, which is why it's not described in the
> manual.
> 
>   mk> So I have to escape the :: somehow. But how?
> 
> You can't.
> 
>   mk> Giving up ... Is there a way to specify an arbitrary sequence of
>   mk> 8-bit bytes (other than those containing \0) as a target?
> 
> No.
> 
>   mk> Having :: as part of a target is a perfectly normal thing under
>   mk> Unix, e.g. for man pages of Perl classes.
> 
> Unfortunately, spaces and colons are not supported in filenames handled
> by make.

OK, understood. It would be very useful if you could explicitely say all
of the above in the manual. This way someone like myself will not have
to spend an hour searching through the manual forward and backward for
a description or even a hit of how to do it.

Are colon and space really the only bytes that cannot be handled in
a filename by make? How would you handle a pathologic filename that
contains bytes such as 0xa0?

POSIX says

  Applications shall select target names from the set of characters
  consisting solely of periods, underscores, digits, and alphabetics from
  the portable character set (see the Base Definitions volume of IEEE Std
  1003.1-2001, Section 6.1, Portable Character Set). Implementations may
  allow other characters in target names as extensions. The interpretation
  of targets containing the characters '%' and '' is
  implementation-defined.

  http://www.opengroup.org/onlinepubs/009695399/utilities/make.html

So it would be good to have a brief section in the manual that explains,
which characters are exactly allowed in file names to be processed by
GNU make.

> That would be a good thing, but it's not that simple.  While quoting
> colons would probably be doable in GNU make, although as you point out
> not really backward compatibly, handling whitespace in a really robust
> way would probably require rewriting virtually all the internals of
> make.  Make is basically a big string handler, and strings are chopped
> up into words (based on whitespace) all the time, multiple times per
> string, in many various contexts.  To get it "really" right you'd
> probably need to replace all that simple string handling with some kind
> of "smart string".

I guess, it would have to move from handling just strings to handling
arrays of fully 8-bit transparent strings, more like what bash, tcl, or
perl do.

> Actually I had one idea that could be implemented without redoing all of
> make's internals, but it would block off at least one and probably two
> or more different 8-bit values from appearing in makefiles.  In an i18n
> world I don't know if this is acceptable.

The i18n world is now fairly quickly moving towards using UTF-8, and
UTF-8 strings have the useful property that the bytes 0xfe and 0xff are
never used by the encoding. Other than that, using bytes in the
0x01-0x1f range may also be acceptable, because none of the
ASCII-compatible character encodings used worldwide uses any of these to
represent a graphicval character. (Well, there is VSCII-1 in Vietnam,
but hardly anyone really uses that under Unix, as it causes endless
problems and has de-facto already been superceeded by UTF-8.)

Markus

-- 
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__