Howdy Ralf,
I so sometimes instruct them to do that, usually when helping people
interactively, and I get mixed results. Some get it right and I get a
condensed log, some actually don't and I end up spending even more time trying
to figure out what went wrong on their end (typos, misunderstand
Hi Sean,
* Christopher Sean Morrison wrote on Sat, May 20, 2006 at 07:26:39PM CEST:
>
> Usually, the problem from a purely practical standpoint is that the
> error is rarely at the very end, it's somewhere probably in the last
> 50-200 lines or so of the output depending on the situation. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for that response. I agree fully with your evaluation of the
problem at hand with overly verbose log files. I was unaware of that
application you mentioned, I may have a look for it later. Thanks again.
Due to various reasons, I have decided t
Date: Mon, 24 Apr 2006 23:29:34 +1000
From: Brendon Costa <[EMAIL PROTECTED]>
Subject: Re: Reducing verbosity of automake
To: automake@gnu.org, Brendon Costa <[EMAIL PROTECTED]>
All patches I've seen add quite a bit of bloat to Makefile.in's, for
dubious value (remember th
* Brendon Costa wrote on Mon, Apr 24, 2006 at 03:29:34PM CEST:
>
> I can imagine that a makefile only based solution would add a lot of
> bloat to the Makefile.in files. There is another solution, but it
> requires a script that behaves like a layer between make and any system
> command it executes
Brendon Costa wrote:
Seems pretty reasonable to me, but I'd suggest a little tweak:
#! /bin/sh
#
DESCRIPTION=$1
COMMAND=$2
shift
shift
echo $DESCRIPTION
< $COMMAND $* > /dev/null
---
> output=`$COMMAND ${1+"$@"}`
RESULT=$?
if test $RESULT -ne 0; then
>exec 1>&2
echo "Command fail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I'm afraid that I misinterpreted what the original poster wanted to be
> a way of tidying output on a single development system, and not for all
> variations of platforms where the build process would be run. The filter
> would be a quick way of scra
I wrote:
> > It might be a nice feature to add this to the autotools, but is it
> > really necessary? Why not follow the unix philosophy and write your
> > own filter (using sed, python, perl, whatever) that reduces the
> > verbose lines you don't want into something more managable?
[EMAIL PROTECT
Hello all,
On Tue, Apr 25, 2006 at 09:13:01AM +0200, Duncan Gibson wrote:
> > C++ ./out/netbsd/debug/src/libs/System/unix/UnixUtils.o
> > C++ ./out/netbsd/debug/src/libs/System/unix/Utils.o
> > Archive ./out/netbsd/debug/src/libs/libADS_System.a
> > Ranlib ./out/netbsd/debug/src/libs/libADS_System
Brendon Costa <[EMAIL PROTECTED]> wrote:
> ...
> When compiling a project using: autoconf/automake/libtool, there is just
> too much data being output to the screen when i run the make command. In
> the jam system i am porting over if I was to issue the jam command, it
> would print messages like:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well i had a small look at the proposal i made last night, and it seems
that it is not possible to achieve what i was saying entirely from
autoconf by setting the command variables to be prefixed with the script
command. Reasons include:
1) It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
> [ I assume you want Cc:s to both addresses? ]
Yep. Thanks.
By the way. Thanks for the reply. I couldn't believe it was so fast :-)
> All patches I've seen add quite a bit of bloat to Makefile.in's, for
> dubious value (reme
[ I assume you want Cc:s to both addresses? ]
Hi Brendon,
* Brendon Costa wrote on Mon, Apr 24, 2006 at 02:20:15PM CEST:
>
> When compiling a project using: autoconf/automake/libtool, there is just
> too much data being output to the screen when i run the make command.
make -s
or even
mak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
I have just recently started using automake and have been attempting to
port over a system that uses jam to now use automake. While doing this i
have come across a feature i seem unable to find within automake. I have
searched the mail
14 matches
Mail list logo
