[bug #34519] Interrupt/Exception caught Program Files (x86)
Follow-up Comment #2, bug #34519 (project make): This fix addresses the issue: diff make-3.82/read.c [...] 3031c3031 const char *e = s + nlen; --- const char *e = p + nlen; ___ Reply to this item at: http://savannah.gnu.org/bugs/?34519 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark
URL: http://savannah.gnu.org/bugs/?34530 Summary: make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark Project: make Submitted by: dankegel Submitted on: Tue 11 Oct 2011 04:58:03 PM GMT Severity: 3 - Normal Item Group: Enhancement Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.82 Operating System: None Fixed Release: None Triage Status: None ___ Details: As Markus wrote in http://lists.gnu.org/archive/html/bug-make/2004-10/msg00013.html gnu make uses funny quotes in error messages. This behavior persists in Make 3.82. Here's his original message: $ make --version GNU Make 3.80 $ make love make: *** No rule to make target `love'. Stop. ^ The use of ASCII character 0x60 as a left single quotation mark is deprecated and looks today rather ugly with most contemporary fonts. Suggested behavior (in the C and POSIX locales, i.e. without translation): $ make love make: *** No rule to make target 'love'. Stop. ^ In other locales, such as en_*.UTF-8, the straight single quotation mark (U+0027) can easily be translated via gettext() with the typographically nicer ones (U+2018 and U+2019) available in UTF-8 and some other encodings. Suggested fix: a) s/`/'/g b) use Unicode quotation marks in the translations for en_GB.UTF-8 and en_US.UTF-8 Detailed background information: http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html ___ Reply to this item at: http://savannah.gnu.org/bugs/?34530 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Mon, 2011-10-10 at 23:59 +0200, Sebastian Pipping wrote: On 10/03/2011 06:22 PM, Sebastian Pipping wrote: To re-summarize: - make does not color its output itself as of now - colorized output would help distincing output by make from output by programs involked by make, example at [1] - existing wrappers (like colormake [2]) have problems - There is a quickhack patch against make 3.82 at [3] - I am willing to keep working on that patch until you like it enough to apply it upstream - I don't know about your expectations on such a patch yet, but I need to know. Please get back to me on this. Thanks! Another week has passed by. Paul, can I have your opinion on this? I have no problem with the concept of colorized output, as long as it meets the following requirements: * The default is no color mode as now * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. * The color designation is flexible: the last thing I want to do is get into a situation where we are scrambling to find acceptable colors for those who prefer terminals with light backgrounds, dark backgrounds, color blind folks, etc. I also don't want to have a new ~/.makerc file or something just to define color schemes. * Based on the above it seems like the code required to implement this will be sufficiently large that it will require copyright assignment to the FSF. * Patches based on the current CVS latest version of GNU make are easier for me to examine/apply/test. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello! On 10/11/2011 07:51 PM, Paul Smith wrote: I have no problem with the concept of colorized output, as long as it meets the following requirements: * The default is no color mode as now Agreed. * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. No plans on using ncurses here. I suppose if we do what grep does were safe enough portability-wise? I'll check what I can learn from there. Regarding complexity it may (or may not) be necessary to split newlines off some translations strings and concat them at runtime, instead. It depends on the question if \n itself should be colorized or not. In general I don't expect much complexity. * The color designation is flexible: the last thing I want to do is get into a situation where we are scrambling to find acceptable colors for those who prefer terminals with light backgrounds, dark backgrounds, color blind folks, etc. Customizable, yes. I also don't want to have a new ~/.makerc file or something just to define color schemes. Okay. I guess that leaves command line options, environment variables or both. Any preferences? * Based on the above it seems like the code required to implement this will be sufficiently large that it will require copyright assignment to the FSF. Alright. Please initiate the copyright assignment process. * Patches based on the current CVS latest version of GNU make are easier for me to examine/apply/test. Sure. I will follow GNU make CVS in this new Git repo of mine [1]. I have ported patch v1 presented earlier to the current state in CVS. It's in branch color-v1.1 of [1], this URL [2] serves a raw patch. I noticed that there is no bootstrap/autogen.sh script in CVS. What do I need to run to bootstrap GNU make? It seems that # autoreconf -i ./configure make leaves me with a repeated warning [..] configure.in:128: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body [..] from autoreconf and a File be.po does not exist error from make: [..] make[4]: Entering directory `/home/sping/__playground/make/po' File be.po does not exist. If you are a translator, you can create it through 'msginit'. make[4]: *** [be.po-create] Error 1 [..] Could you add a bootstrap/autogen.sh script to CVS? Best, Sebastian [1] http://git.goodpoint.de/?p=make.git;a=summary [2] http://git.goodpoint.de/?p=make.git;a=patch;h=c901be5018830bbc5d9b2cac553fd4174189659b ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Wed, 2011-10-12 at 00:05 +0200, Eli Zaretskii wrote: Date: Tue, 11 Oct 2011 22:11:23 +0200 From: Sebastian Pipping sebast...@pipping.org * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. No plans on using ncurses here. I suppose if we do what grep does were safe enough portability-wise? I'll check what I can learn from there. Please don't assume that writing some special character sequences to stdout is all that's needed. This is so on Posix platforms, but not Windows or DOS. To be truly portable, there should be an API that accepts a string and the information how to color it, and then a platform-specific backend actually produces the colored output and writes it to the screen. Right. It's OK to look at how GNU grep does it, but GNU make is actually far more portable than GNU grep, which is really a POSIX tool and more tightly tied to POSIX systems. GNU make, in addition to POSIX systems, also runs on Windows, DOS, Amiga/OS, even OpenVMS. Plus not all POSIX systems use the same colorization models; really colorization depends on the terminal type not the OS (at least for POSIX systems). vtxxx, pcansi, and xterm terminals may use very different colorization codes than some other terminal type. Anyway, it's not necessarily the case that a feature implemented only on a subset of supported platforms will be rejected. But, it needs to be implemented in such a way that it doesn't break on unsupported platforms and that it's easy and clean to extend to work on other platforms if someone wants to do so. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
