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:[EMAIL PROTECTED] On Behalf Of Paul D. Smith Sent: Monday, June 28, 2004 3:18 PM To: Asperheim, Eric Cc: [EMAIL PROTECTED] Subject: RE: repost - target with a colon in the name %% "Asperheim, Eric" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-make
