Hi automakers,
probably this is an oftne asked and therefore annoying question ... but
is there a simple way to get automake to produce a similar output as the
Linux kernel makefiles?
Instead of this verbose confusing output like automake makefiles, the
kernels make produces something like
[
Stefan,
I asked this very question a few years ago on this list.
Interestingly, my examples came not from the Linux kernel build
process, but from Windows builds, which use a similar output format. I
love this format because warnings and errors are obvious, and yet you
get enough output per file
Some work on improving make output (pretty-printing) has been done for
Xerces-C http://xerces.apache.org/xerces-c/
See also this bugreport http://issues.apache.org/jira/browse/XERCESC-1440
You may want to ask about it on one of the mailing lists
On 2008-04-11 16:28, John Calcote wrote:
Stefan,
I asked this very question a few years ago on this list.
Interestingly, my examples came not from the Linux kernel build
process, but from Windows builds, which use a similar output format. I
love this format because warnings and errors are
John Calcote wrote:
I love this format because warnings and errors are obvious, and yet
you get enough output per file to tell you that something's going
on.
To give you a different perspective, I *hate* that format because it
hides problems and *makes debugging harder*. I want to see exactly
Bob Proulx wrote:
To give you a different perspective, I *hate* that format because it
hides problems and *makes debugging harder*. I want to see exactly
the command that was executed. I want to see the entire command. I
don't want to see an abbreviation of the command.
Fortunately, no one
On Fri, Apr 11, 2008 at 10:36 AM, Robert J. Hansen
[EMAIL PROTECTED] wrote:
Bob Proulx wrote:
Always build with full warnings enabled. Always clean up warnings as
they are introduced. Always keep a warning free build.
Given the wide leeway the C and C++ standards give implementors in
* Robert J. Hansen wrote on Fri, Apr 11, 2008 at 06:36:56PM CEST:
Bob Proulx wrote:
To give you a different perspective, I *hate* that format because it
hides problems and *makes debugging harder*. I want to see exactly
the command that was executed. I want to see the entire command. I
On Fri, 11 Apr 2008, Ralf Wildenhues wrote:
When Alexandre last commented on a request like this, one comment that
wasn't already mentioned in this thread was this issue: a patch for
nicer output should not cause hugely increased Makefile.in files.
Makefile.in size is an issue for some larger
Robert J. Hansen wrote:
John Calcote wrote:
Hmmm. I'd have to disagree here. I carefully consider every warning I
see, and evaluate whether or not it represents a real problem.
Yes. This strikes me as perfectly sane behavior.
I also agree with this. Using reasonable judgement is a good
On Fri, Apr 11, 2008 at 3:00 PM, Bob Proulx [EMAIL PROTECTED] wrote:
When you want to clean up the warnings (usually something done near
the end of a development cycle), you simply build with stdout
redirected to /dev/null when you run make a few times, and you'll
see the warnings
* John Calcote wrote on Fri, Apr 11, 2008 at 11:18:48PM CEST:
Anyway, what I meant was that my
development cycles are fairly short - I might not get around to
checking for warnings (by redirecting stdout to /dev/null) for a few
days, so I might let a few warnings go for a week (or less), if
On Fri, Apr 11, 2008 at 5:28 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote:
I can't understand why people do edit-compile-test cycles without having
compiler output be post-processed by their editor. It works with all
decent unix editors, and it's even more comfortable than not having to
go
13 matches
Mail list logo