On 02/28/2012 08:12 PM, Sebastian Pipping wrote:
Without looking any closer than your email I may prefer to handle this
through the maintainer build step, rather than committing gnulib files
directly to the make source control. But I'll have to investigate.
I'm aware this can be done off-
On 02/28/2012 05:37 PM, Paul Smith wrote:
On Mon, 2012-02-27 at 17:39 +0100, Sebastian Pipping wrote:
If been playing with gnulib integration by now:
Thanks Sebastian. I'll take a look at this but probably not until the
weekend. I was on vacation (scuba diving from a live-aboard off
On Sun, 2012-02-12 at 19:34 +0200, Eli Zaretskii wrote:
Date: Sun, 12 Feb 2012 18:11:49 +0100
From: Sebastian Pipping sebast...@pipping.org
CC: psm...@gnu.org, bug-make@gnu.org
Since we would run into buffer overflows with sprintf/vsprintf, we
rely on snprintf/vsnprintf for that task.
On 02/13/2012 05:41 PM, Paul Smith wrote:
Pulling in an implementation from gnulib, just in case, might be the way
to go.
This seems to be the entry point:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/vasnprintf
I'd make a new directory gnulib and copy needed files
On 02/12/2012 05:27 PM, Eli Zaretskii wrote:
Date: Sun, 12 Feb 2012 05:07:48 +0100
From: Sebastian Pipping sebast...@pipping.org
CC: psm...@gnu.org, bug-make@gnu.org
So far both of these have been requirements: (1) keep the overall format
translatable so other languages can adjust order of
Date: Sun, 12 Feb 2012 18:11:49 +0100
From: Sebastian Pipping sebast...@pipping.org
CC: psm...@gnu.org, bug-make@gnu.org
Since we would run into buffer overflows with sprintf/vsprintf, we
rely on snprintf/vsnprintf for that task. Quoting from my man 3
printf output:
snprintf(),
Hello again,
with v5 [1] of the color patch we have moved into a situation where a
choice needs to be made:
- either we require/bundle/re-write CRT function vsnprintf or
- we sacrifice the ability to translate the order of message
components (i.e. _(%s:%lu: %s%s%s%s) and two friends)
Date: Sun, 12 Feb 2012 02:04:47 +0100
From: Sebastian Pipping sebast...@pipping.org
Cc: bug-make@gnu.org
with v5 [1] of the color patch we have moved into a situation where a
choice needs to be made:
- either we require/bundle/re-write CRT function vsnprintf or
- we sacrifice the
On 02/12/2012 05:03 AM, Eli Zaretskii wrote:
Date: Sun, 12 Feb 2012 02:04:47 +0100
From: Sebastian Pipping sebast...@pipping.org
Cc: bug-make@gnu.org
with v5 [1] of the color patch we have moved into a situation where a
choice needs to be made:
- either we require/bundle/re-write CRT
The other thing I wonder about is the hardcoding of ASCII colorized
strings and the start/stop character strings (\033[...). Are there
other methods of colorizing?
Yes.
Indeed - most obviously, anyone running a build-'bot that reports its
build logs via the web (it's a common solution for
Hello, great to hear from you.
On 01/04/2012 02:06 AM, Paul Smith wrote:
On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote:
I have to say that I feel that David's
point of 20 Oct is well-taken, that a more flexible command line
interface would be better.
Alright. I propose to
Hello again,
I have integrated your review into a new version of the color patch.
Version 4 is up at http://hartwork.org/public/make-CVS-color-v4.patch .
There are the changes since the last version:
# git log --oneline | tac | tail -n 5
b9aaec5 Revert addition of 2011 to copyright years
On Thu, 2012-01-05 at 19:29 +0100, Sebastian Pipping wrote:
I confess I'm not an expert in i18n, so it's quite possible I'm making
something out of nothing very important here. But I think it's worth
investigating. It's possible, for example, that it's sufficient to
translate the prefix
From: Paul Smith psm...@gnu.org
Date: Thu, 5 Jan 2012 15:20:07 -0500
Cc: bug-make@gnu.org
The other thing I wonder about is the hardcoding of ASCII colorized
strings and the start/stop character strings (\033[...). Are there
other methods of colorizing?
Yes.
Should we try to support
On 01/05/2012 09:20 PM, Paul Smith wrote:
What I mean is, instead of voutputf() invoking multiple calls to
fprintf(), we'd need to compute all the strings we needed then invoke a
single fprintf() for each output style where the format string was
translated, something like this:
if
On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
The easiest way of abstracting this is to have a function that turns
on a given color, and another function that turns off a color and
returns to the default color. (Color can actually be some other
attribute, like bold or blinking.) There should
On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote:
On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
The easiest way of abstracting this is to have a function that turns
on a given color, and another function that turns off a color and
returns to the default color. (Color can actually
On Thu, 2012-01-05 at 22:35 +0100, Sebastian Pipping wrote:
Function vsnprintf could be used to fill variable output.
Quoting the local printf(3) man page:
Erhm. Forgot about that: neither vsprintf() nor vsnprintf() were
included in the C89 standard. They were added in the C99 standard.
Updates as requested:
# git log --oneline | tac | tail -n 2
8e3918a Move output.(c|h) code to output_ascii.(c|h), make
output.(c|h) a null layer
00d24e4 Reduce to single translated call to fprintf, extract
functions (start|stop)_color
From: Paul Smith psm...@gnu.org
CC: Eli Zaretskii e...@gnu.org, bug-make@gnu.org
Date: Thu, 5 Jan 2012 17:32:50 -0500
On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote:
On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
The easiest way of abstracting this is to have a function that
Date: Thu, 05 Jan 2012 22:42:15 +0100
From: Sebastian Pipping sebast...@pipping.org
CC: psm...@gnu.org, bug-make@gnu.org
On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
The easiest way of abstracting this is to have a function that turns
on a given color, and another function that turns off
On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote:
I have to say that I feel that David's
point of 20 Oct is well-taken, that a more flexible command line
interface would be better.
Alright. I propose to transform
--output-format=(color|plain)
into
On 11/13/2011 05:21 PM, Paul Smith wrote:
I'll look at your code today.
Any news?
I have to say that I feel that David's
point of 20 Oct is well-taken, that a more flexible command line
interface would be better.
Alright. I propose to transform
--output-format=(color|plain)
into
On Fri, 2011-11-11 at 22:42 +0100, Sebastian Pipping wrote:
the copyright assignment form reached the FSF more than a week ago.
Would be great to get some more review on my patch now.
I don't mind if on-list, off-list, half-half...
Hi Sebastian. I got notified by the FSF that your
Hello,
the copyright assignment form reached the FSF more than a week ago.
Would be great to get some more review on my patch now.
I don't mind if on-list, off-list, half-half...
Paul?
Thanks,
Sebastian
___
Bug-make mailing list
Hello again,
I've been doing more work on the patch. Version 3 is up at [1]. Since
version 2 I have made these changes:
- Fix: error() printed twice (first with color, then a second
time without)
- Add support for customizing colors through environment
variable MAKE_COLORS
On 10/20/2011 06:40 AM, Paul Smith wrote:
However it can take a bit to complete esp. if you reside outside the
U.S. (inside the U.S. we can now use scanned documents via email but
outside the U.S. we still must rely on physical mail).
Outside U.S., yes.
I'll send you some options and you
Hello again!
I have some new code ready for you to tear apart, err review :-)
I have re-written the patch so that version 2 at [1] does the following:
- Add parameter --color[=(yes|no)] to enable/disable color
from the command line. Minimal man page entry added, too.
- Integrate
Date: Thu, 20 Oct 2011 20:19:33 +0200
From: Sebastian Pipping sebast...@pipping.org
I have some new code ready for you to tear apart, err review :-)
Here's mine:
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case
On Thu, Oct 20, 2011 at 2:19 PM, Sebastian Pipping
sebast...@pipping.org wrote:
- Add parameter --color[=(yes|no)] to enable/disable color
from the command line.
Previously, I suggested XML output piped to a colorizing filter and
you indicated a lack of interest in going that way. Which is
Hello David,
to be honest I don't think that --output-format=color is a good choice
with regard to usability (or the human factor). Also, it lacks the
at-home-feeling for users of grep that --color provides.
Best,
Sebastian
___
Bug-make mailing
On 10/20/2011 08:43 PM, Eli Zaretskii wrote:
Date: Thu, 20 Oct 2011 20:19:33 +0200
From: Sebastian Pipping sebast...@pipping.org
I have some new code ready for you to tear apart, err review :-)
Here's mine:
Thanks Eli!
+ /* Determine target file (i.e. stdout or stderr) and color to
Date: Fri, 21 Oct 2011 00:33:51 +0200
From: Sebastian Pipping sebast...@pipping.org
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case OT_DIR_ENTER: target = stdout; color = color_dir_enter; break;
+ case
On 10/11/2011 10:11 PM, Sebastian Pipping wrote:
Alright. Please initiate the copyright assignment process.
Any news on this? So there are no preperations to do?
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
On 10/12/2011 12:05 AM, Eli Zaretskii wrote:
[..] 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.
That's a good idea, actually.
Best,
On Thu, 2011-10-20 at 05:56 +0200, Sebastian Pipping wrote:
On 10/11/2011 10:11 PM, Sebastian Pipping wrote:
Alright. Please initiate the copyright assignment process.
Any news on this? So there are no preperations to do?
The paperwork generally requires you to list the files that you
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,
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
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
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
On Mon, Oct 3, 2011 at 12:40 PM, Tim Murphy tnmur...@gmail.com wrote:
I have no decision making abilities so this comment is just an observation
Similarly, I'm just a bystander who should be doing real work.
Whatever people decide to do, I'm interested in being able to parse
the output of
On 10/03/2011 08:20 PM, David Boyce wrote:
I have two reactions to the original post:
1. I hate colorized output in all its forms. If you want to add this
feature and can get it in that's fine with me as long as it will never
show up as a default in any native build of make.
Off-by-default
Hello!
First, here's a picture of what this is about: [1].
Wrappers like colormake [2] have a number of problems: they cannot
distinguish certain lines of output (like commands being executed and
output produced by these very commands), they take more resources than
needed just to name a few.
43 matches
Mail list logo
