Re: make cannot handle prerequisites that contain a colon
> Date: Mon, 2 Oct 2006 15:22:04 +0200 > From: "Holleman, Bas" <[EMAIL PROTECTED]> > > Yes, that is true. On Windows, the PATH environment variable can have > more than 256 characters. And I think it is the problem and something > like this happens if PATH is to long: gmake can not handle so much > characters and it reads only a part of the PATH variable. Because of > this, gmake can not find some of the programs it needs and it generates > bad commands, which Windows (?) handles by displaying messages like > "begin_process: CreateProcess((null),...". I don't see any such limitations in gmake. If you can show an example of a Makefile that fails because of a long PATH, please do, and I will try to investigate. ___ Bug-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-make
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 [email protected] 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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-make
Re: make cannot handle prerequisites that contain a colon
%% Andreas Buening <[EMAIL PROTECTED]> writes: ab> 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. ab> If I've been told correctly, then the special about UTF-8 is that ab> is takes all 7 bit characters as they are, i.e., a space is still ab> a space. Only 8 bit character can have a special meaning. True. But there are some (low) 7-bit characters which are extremely unlikely to appear in a filename, which could also be used. I don't know that it's a requirement to support every single legal character that _might_ appear in a filename. For example, things like ASCII 0x01 (and thus UTF-8 0x01), etc. are pretty unlikely to appear in filenames that anyone would ever want to use with make. -- --- 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
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
%% Markus Kuhn <[EMAIL PROTECTED]> writes: mk> Are colon and space really the only bytes that cannot be handled mk> in a filename by make? How would you handle a pathologic filename mk> that contains bytes such as 0xa0? Well, filenames that contain newlines can't be represented either. Make uses standard char* strings to hold all its data, not unsigned and not wchar_t. But, it doesn't do much with these strings except chop them up on whitespace, compare them, and send them to programs it invokes. So, offhand I can't see any reason why higher-bit set characters would be a problem. mk> So it would be good to have a brief section in the manual that mk> explains, which characters are exactly allowed in file names to be mk> processed by GNU make. True, but that would require someone testing to see which ones work :-). In other words, there's nothing in GNU make that actually looks at target names to make sure they contain only a valid set of characters. If there _ARE_ restrictions then they exist as a side-effect of processing by some other area of GNU make. mk> I guess, it would have to move from handling just strings to mk> handling arrays of fully 8-bit transparent strings, more like what mk> bash, tcl, or perl do. Well, it's pretty complicated when you start looking at the details of how such a thing could work, given the free-form syntax of makefiles. >> 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. mk> The i18n world is now fairly quickly moving towards using UTF-8, mk> and UTF-8 strings have the useful property that the bytes 0xfe and mk> 0xff are never used by the encoding. Other than that, using bytes mk> in the 0x01-0x1f range may also be acceptable, because none of the mk> ASCII-compatible character encodings used worldwide uses any of mk> these to represent a graphicval character. (Well, there is VSCII-1 mk> in Vietnam, but hardly anyone really uses that under Unix, as it mk> causes endless problems and has de-facto already been superceeded mk> by UTF-8.) That's good to know; one of the main problems I've had with trying to find a solution to the issue is not having any personal understanding of how the various extended character sets actually work and what would be possible or not possible with them. 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. 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. -- --- 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
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
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
