colorizing abc\n, should color stop before or after \n?
- The make code seems to support a variety of platforms.
Which platforms should receive color, which shouldn't?
Looking forward to hear from you!
Best,
Sebastian Pipping
[1] http://hartwork.org/public/make-with-color.png
[2] http
On 09/29/2011 08:57 AM, wu peter wrote:
Hello
I am Peter .I use make install,but there are some errors as
follow. Thanks for your answer.
Is it the problem that I am not the root.
for dir in libint libr12 libderiv; \
do \
(cd ${dir} make install) || exit 1; \
done
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
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
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 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
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 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
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
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 11/07/2011 11:11 AM, andrec wrote:
On win32 systems :
# Thanks Blackthorne, for corrections on the *.c rule
SRC = *.c
CFLAGS = -Wall -shared -g
GLUT_DIR = src/glut/glx
$(GLUT_DIR)/$(SRC) : $(GLUT_DIR)/*.h
glut32.dll :
gcc $(CFLAGS) $(GLUT_DIR)/$(SRC) -o glut32.dll
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
Follow-up Comment #2, bug #34806 (project make):
Would it be easy to isolate the related patch for you? If so, distros could
integrate that before 3.83 comes out. So if it's easy, please attach the
patch applied. Thanks!
___
Reply to
Follow-up Comment #2, bug #34608 (project make):
Thanks for these details. Let me propose
#define INTEGER_TYPE_SIGNED(t) !((t) -1 0)
for a warning-less replacement then. Like it?
Please re-open the bug for me, as I lack permissions to.
I used the program below with
# gcc -Wall -Wextra
Follow-up Comment #3, bug #34530 (project make):
If Markus is on a crusade for it, does that make him wrong?
I thought we were on a joint crusade for free software with GNU make.
Paul, are you sure such a change would even be hitting translators? Either
`foo' has been translated to `foo' so we
Follow-up Comment #4, bug #34608 (project make):
Can you re-open the bug until you made a decision?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34608
___
Message sent via/by
Follow-up Comment #5, bug #34530 (project make):
I was assuming that the strings itself are they keys, already.
Would technically be possible for us to fix the hashes on our end to save the
translators the trouble but still fix the trouble?
I'm unsure if bouncing this back up to GNU level is a
Follow-up Comment #5, bug #34608 (project make):
You mentioned !((t) -1 = 0) .
I do not get any warnings when using that in the mentioned code sample
compiled with -Wall -Wextra and GCC 4.4.5.
What warnings do you get?
___
Reply to this
Follow-up Comment #7, bug #34608 (project make):
Interesting. For you code (with unsigned int) I get the warning, too. For
unsigned char, I don't. No warnings in either case for 0 (as opposed to
= 0.
___
Reply to this item at:
Follow-up Comment #10, bug #34608 (project make):
Very nice, thanks!
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34608
___
Message sent via/by Savannah
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
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
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 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
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
On 01/17/2012 06:28 AM, Eli Zaretskii wrote:
For sure once I actually take the plunge and move to a real source
code control system [...]
May I suggest bzr? It is a GNU project and is used by Emacs, wget,
and a few others on Savannah.
Git please. It's fast, used by important GNU projects
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)
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
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
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/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
Hello,
on page [1] it reads:
CFLAGS should be used in every invocation of the C compiler,
both those which do compilation and those which do linking.
It would be nice to have an explanation why CFLAGS whould be used with
linking, too. Maybe with an example or a dedicated section in the
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
Hello,
On 05/05/2012 11:24 PM, Le Gluon du Net wrote:
Bonjour,
j'aimerai compiler le snapshot de raine sous Ubuntu 12.04 mais j'ai une
erreur:
$ make
Building Raine, Fully optimized version with gcc for linux-gnu CPU=pentium-m
dependencies : if you get an error here, install the
On 06/19/2012 10:19 PM, igle...@unifesp.br wrote:
Dear Sirs,
I am tryinng to install root (cern) in ubuntu 12.04 in order to run a R
package called xps. I could install root following many posts advices (I
am not an expert on linux) and the tutorials run fine. However, I can
not install the
Hello Eric,
On 10/13/2012 05:09 PM, Eric Seerden wrote:
Hi all,
I'm trying to get in contact with Paul D. Smith who worked with rms on
the GNU make (gmake) utility apparently he is now the maintainer of
the software..
Many thanx in advance for your help..
Since you have the attention
Hello,
please try to use a more to the point mail subject line next time.
Especially !!! should be avoided: it cuts down the number of people
willing to even read the mail body by a half easily. I doubt that's in
your interest :-) Thanks.
Best,
Sebastian
Hello Jack,
On 22.12.2012 15:20, Jack Riegel wrote:
I created a 2-line fortran program and a simple make file (below) to
illustrate the problem that I am having. When I run make, I get the
following output. Note that if I simply copy and paste the final
gfortran line (the linking step)
On 01.02.2013 16:18, Matěj Týč wrote:
Hi,
I have noticed that if we have a target that has prerequisities, if
those prerequisities are missing and I want to make the target, then
even if the target file exists, prerequisities are remade if possible
and then, consequently, the target has to be
On 02.02.2013 16:19, Matěj Týč wrote:
This is what I understand to be our current Makefile:
bar_deps = foo1 foo2
bar: $(bar_deps)
$(bar_deps): | cache-foo
%:
touch $@
[..]
Thank you for your quick help, your example indeed works, but it has one
weakness.
Consider a
On 02.02.2013 18:38, Matěj Týč wrote:
How about something like this?
bar_deps = foo1 foo2
bar: $(bar_deps)
$(bar_deps):
$(MAKE) cache-foo
touch $@
%:
touch $@
I have also thought of that, but this can work well reliably only in the
case if there is only one
On 03.02.2013 23:20, Matěj Týč wrote:
If that happens how about replacing
$(MAKE) cache-foo
by something like
mkdir .lock 2/dev/null || exit 0 ; \
$(MAKE) cache-foo ; \
ret=$$?; \
rmdir .lock exit $${ret}
The idea is:
- mkdir can only succeed once
- if
On 04.02.2013 00:13, Matěj Týč wrote:
On Ne, 2013-02-03 at 23:40 +0100, Sebastian Pipping wrote:
To my understanding, it would have to be optional and off by default to
not break other cases that are currently supported. Think of something like
tmp:
mkdir tmp
tmp/foo.pdf: foo.tex
Hello Karl-Heinrich,
to me it looks like you are having trouble compiling Cinelerra 4.4.
This mailing list is dedicated to issues with GNU make itself.
You might want to write to help-m...@gnu.org, instead, see Mailing
Lists on [1].
Also, please make sure to share English program output rather
Hello Karl-Heinrich,
to me it looks like you are having trouble compiling Cinelerra 4.4.
This mailing list is dedicated to issues with GNU make itself.
You might want to write to help-m...@gnu.org, instead, see Mailing
Lists on [1].
Also, please make sure to share English program output rather
On 22.02.2013 03:31, Ian Lynagh wrote:
Hi all,
The attached Makefile causes an infinite loop with parallel make when
using make 3.81 (on amd64/Linux):
$ make setup
touch B.hs A.hs
sleep 2
touch B.hi B.dyn_hi
sleep 2
touch B.o B.dyn_o
sleep 2
touch
On 25.02.2013 14:57, Brian J. Murrell wrote:
Hi,
I have run into something I find strange with GNU Make 3.81 (yes, I know
3.82 is latest but since it's not in EL6, my target platform, I cannot
depend on it's features).
I would think that given the following set of rules:
/tmp/%.foo:
Follow-up Comment #2, bug #38433 (project make):
Paul and Philipp,
Daniel has a valid point here. You could be a lot more welcoming on this
case, why so hard on him? I hit the very same thing myself some time ago,
just forgot to speak up myself. That documentation bug is the reason meta
51 matches
Mail list logo
