RE: repost - target with a colon in the name

[Asperheim, Eric]

Paul,

Agree that you'd only want to change gmake once for this enhancement.
And, I don't doubt it's a tough problem. You're proposed solution seems
to make sense. But, I'm not in a position to really say one way or the
other.

Again, appreciate your help. And as someone that releases software to a
large user base at Intel, I appreciate the thorny problem of backward
compatibility (to support or not to support). I've always said no to
backward compatibility. Despite getting a couple of hate mails every
once in awhile, most users can understand why additional enhancements
come at the price of having to change something on their side. But, our
software user base is only Intel and not the world.

Thanks,

Eric

-----Original Message-----
From: Paul Smith [mailto:address@hidden On Behalf Of Paul D.
Smith
Sent: Monday, June 28, 2004 3:18 PM
To: Asperheim, Eric
Cc: address@hidden
Subject: RE: repost - target with a colon in the name

%% "Asperheim, Eric" <address@hidden> writes:

  ae> But, few things frustrate me more than backward compatibility
  ae> preventing improvements from being made. If you did add syntax to
  ae> support escaping of : in prereqs, I don't doubt that some
  ae> Makefiles might break. But, I would think that it would be a very,
  ae> very small % of Makefiles. And, those Makefiles could be update to
  ae> work with this new version, i.e. that issue can be fixed within
  ae> the tool. I on the other hand will have to hack around this
  ae> problem since a solution doesn't exist in gmake. So, I don't agree
  ae> that 100% adherence to backward compatibility is the right
  ae> solution. Just my opinion.

I hear you, and with most applications I think there would be little
excuse.  Unfortunately GNU make is, IMO, in a slightly different
category, since it's such a fundamental tool for all kinds of
development efforts.


However, I would be willing to break backward-compatibility to solve
these issues _BUT_ I would only be willing to do it _ONCE_.  That means
that _all_ the quoting and escaping problems would need to be resolved
at the same time, and resolved "the right way".  So we're not just
talking about ":" here, but also some answer for whitespace in
filenames, etc. etc.

Solving the ":" problem is not that big of a deal, since colons really
only have special meaning when parsing a rule definition, but the
whitespace problem is extremely difficult because make breaks up words
all the time, all over the place.


My only idea so far (that doesn't involve completely rewriting the way
make stores and handles strings internally) is to allow make to map
special input characters to special storage characters.  For example, a
"non-breakable" space that was part of a filename could be mapped to an
ASCII 0x01, a colon to a 0x02, etc.  These would then not be considered
special by any make function or tool that walked strings looking for
whitespace.  Then just before make invokes and subcommand it could do a
final pass on the command lines converting the special characters back
into their respective values.  This needs to be very carefully thought
out, of course.

Obviously the input mechanisms that specified when make should translate
a space into a "meta-space" would need to be defined; some are obvious,
like wildcard would return mapped filenames and references to files
coming from the command line would be mapped.  In other situations we
could define a syntax (I've always thought something like $[...] would
be a good syntax that might mean "take these contents literally as a
single word"--I prefer backslash quoting since that the most common way
but this is a problem for Makefiles written for Microsoft operating
systems.


The problem with this is that given i18n etc. I just don't know that
there _are_ any special characters I could use that would not be
expected to appear in makefiles.  Someone who was more familiar with
this issue than I would need to be consulted.

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