"Paul D. Smith" wrote on 2004-10-18 00:26 UTC: > %% Markus Kuhn <[EMAIL PROTECTED]> 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__ _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
