Re: make cannot handle prerequisites that contain a colon
From: Bas Holleman [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 10:01:16 + (UTC) Hi Sebastien, About the problem: gmake begin_process CreateProcess failed. I cannot find the beginning of this thread in the archives. This is my experience: The Windows PATH variable is to long. gmake runs in something like a DOS environment. It can not handle more than 256 characters. This is not true: On Windows, PATH can have much more than 256 characters. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make cannot handle prerequisites that contain a colon
Hi Sebastien, About the problem: gmake begin_process CreateProcess failed. This is my experience: The Windows PATH variable is to long. gmake runs in something like a DOS environment. It can not handle more than 256 characters. The solution: delete from the PATH variable what you don't need. Good luck! Bas Holleman ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make cannot handle prerequisites that contain a colon
Paul D. Smith wrote: The idea I had involves changing escaped special characters like spaces into impossible byte values in make's internal string representation. That way all of make's current manipulation would continue to work as-is: when searching for whitespace to break up words for example it would not see the impossible byte values as whitespace, so it wouldn't break on that character. If I've been told correctly, then the special about UTF-8 is that is takes all 7 bit characters as they are, i.e., a space is still a space. Only 8 bit character can have a special meaning. Bye, Andreas ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
Re: make cannot handle prerequisites that contain a colon
Paul D. Smith wrote on 2004-10-19 19:31 UTC: I'm not really sure what would be involved with providing support for full UTF-8 character sets in make; I'd have to think about it more. I believe make works already pretty well with UTF-8 as it is. The only thing you really need to think about is whether make depends anywhere on the assumption that 1 byte = 1 character = 1 terminal cell position because both of these equalities are true for ASCII and ISO 8859-1, but not for UTF-8. Is make using anywhere strlen() to estimate how long a string will be on the output terminal? I don't think it does any form of column formatting, or the like. Does make have any form of regular-expression matching or globbing, where a sing '.' or '?' is meant to refer to a single character, not a single byte? In that case, these matching algorithms may have to become slightly locale dependent. Does make convert anywhere between uppercase and lowercase characters or make decisions based on some classification of characters? Other than that, there is usually no need to support UTF-8 properly. See http://www.cl.cam.ac.uk/~mgk25/unicode.html and under Linux also man utf-8 for some introductory information on the subject. The idea I had involves changing escaped special characters like spaces into impossible byte values in make's internal string representation. That way all of make's current manipulation would continue to work as-is: when searching for whitespace to break up words for example it would not see the impossible byte values as whitespace, so it wouldn't break on that character. Then, at the very last minute before make invokes a commandline, etc. it would un-translate the string and replace the impossible bytes with the special characters again. Of course, there are many details to work out, such as the user interface for escaping special characters, exactly when the translation back is done, etc. That sounds at first glance quite feasible to be (but then, I'm not really familiar with make's internals). 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
Re: make cannot handle prerequisites that contain a colon
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
make cannot handle prerequisites that contain a colon
GNU Make 3.80 (as shipped with SuSE Linux 9.1) BUG1: The GNU make 3.80 manual lacks a section on quoting of special characters that describes how any arbitrary byte sequence can be provided as a prerequisite or a target in a rule. There are only brief discussions on how to quote % and $, but not on how to quote other bytes. BUG2: I tried to specify a target named 'a::b': all: a::b a\:\:b: touch $@ This leads (presumably correctly) to the error Makefile:1: *** target pattern contains no `%'. Stop. So I have to escape the :: somehow. But how? I did not succeed in getting past the syntactic restrictions of make. I tried both all: a\:\:b which let to make: *** No rule to make target `a\:\:b', needed by `all'. Stop. as well as TARGET=a::b all: $(TARGET) which led again to Makefile:2: *** target pattern contains no `%'. Stop. Giving up ... Is there a way to specify an arbitrary sequence of 8-bit bytes (other than those containing \0) as a target? I'm apparently not alone with this problem: http://lists.gnu.org/archive/html/help-make/2004-06/msg00138.html Having :: as part of a target is a perfectly normal thing under Unix, e.g. for man pages of Perl classes. I believe that the ability to specify any arbitrary filename in a Make file is so important that any esoteric backwards compatibility problems that a solution to this problem might create would be quite justifyable. Fundamental tools, including make, really need 100% filename transparency using a simple and well-documented quoting mechanism. The obvious suggestion would be to use either \ or $ as an escape symbol, and to provide a command-line option for backwards compatibility. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
Re: make cannot handle prerequisites that contain a colon
%% 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. 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 [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 ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
