Ralf Wildenhues wrote:
For Emacs, all I know was that M-x compile did all that I ever needed.
But I'm sure it can be extended for unusual compiler output as well.
For emacs use M-x compile to build. The default compile command is
make but may be modified as desired. To walk through every
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
14 matches
Mail list logo
