bug-make
[Top][All Lists]
Advanced

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

Re: make cannot handle prerequisites that contain a colon


From: Paul D. Smith
Subject: Re: make cannot handle prerequisites that contain a colon
Date: Sun, 17 Oct 2004 20:26:33 -0400

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

  mk> I believe that the ability to specify any arbitrary filename in a
  mk> Make file is so important that any esoteric backwards
  mk> compatibility problems that a solution to this problem might
  mk> create would be quite justifyable.  Fundamental tools, including
  mk> make, really need 100% filename transparency using a simple and
  mk> well-documented quoting mechanism.

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


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.

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