Hi Stefano,
* Stefano Lattarini wrote on Sat, Dec 05, 2009 at 03:09:34PM CET:
I have rebased my private branch against master, and also amended the
patch a bit (to deal with the test `cscope.test', which used a
`$MAKE 2stderr' redirection that I missed). The updated patch is
attached.
I have rebased my private branch against master, and also amended the
patch a bit (to deal with the test `cscope.test', which used a
`$MAKE 2stderr' redirection that I missed). The updated patch is
attached.
Regards,
Stefano
From e9666da90920c1373bfe6f9cbf8aa1e4e50c2b8a Mon Sep 17 00:00:00
Stefano Lattarini wrote:
Aaargh! There is a bug (another), with heirloom-sh this time.
Apparently, shell traces are not enabled/disabled in run_command()
the way they should.
Please do not apply the patch until I'll had figured out and fixed the
problem (I've no time right now, maybe
Aaargh! There is a bug (another), with heirloom-sh this time.
Apparently, shell traces are not enabled/disabled in run_command()
the way they should.
Please do not apply the patch until I'll had figured out and fixed the
problem (I've no time right now, maybe tomorrow I can do something).
Hello automakers.
The final version of the patch is attached.
Sorry for the long delay, but being new to FreeeBSD I messed up things
more than one time while runnning tests on that system.
The patched testsuite runs succesfully on Debian/Linux with
either bash, zsh 3 or zsh 4. With
Stefano Lattarini stefano.lattar...@gmail.com wrote:
Hi Ralf.
A new version of the patch is attached. It's still not definitive,
but I hope most things are settled by now.
And, of course, they're not. Sigh.
With FreeBSD-7.2 /bin/sh, the construct:
if eval $run_evald_cmd; then
Hi Stefano,
* Stefano Lattarini wrote on Tue, Oct 13, 2009 at 04:24:38PM CEST:
At Tuesday 13 October 2009, Ralf Wildenhues wrote:
First off, I think that run_command really should Exit when the
command does not produce the intended status. It should not be
necessary to do run_command -e
I attached a new version of the patch. Please note that it still
doesn't address the remarks and objections made in the present mail.
At Tuesday 13 October 2009, Ralf Wildenhues ralf.wildenh...@gmx.de
wrote:
Hi Stefano,
I understand. But what about instead susbstituting everywhere
Hi Stefano,
* Stefano Lattarini wrote on Sat, Oct 10, 2009 at 03:04:59PM CEST:
At Saturday 10 October 2009, Ralf Wildenhues wrote:
I didn't make myself clear enough, sorry. What I meant was that we
shouldn't change uses of $AUTOMAKE with redirections to
'run_command $AUTOMAKE' when we
Stefano Lattarini wrote:
...
Hmm, I'm a bit leery of making things read-only, but making sure
the files contain a generated by ... line near the top seems a
good idea.
In truth, I don't find that much useful in order to prevent
unintentional editing: I have ended up too many times modifying
Hi Jim, Stefano,
* Jim Meyering wrote on Sun, Oct 11, 2009 at 01:41:25PM CEST:
Stefano Lattarini wrote:
...
Hmm, I'm a bit leery of making things read-only, but making sure
the files contain a generated by ... line near the top seems a
good idea.
In truth, I don't find that much useful
At Saturday 10 October 2009, Ralf Wildenhues ralf.wildenh...@gmx.de
wrote:
* Stefano Lattarini wrote on Sat, Oct 10, 2009 at 03:42:52AM CEST:
[CUT]
Hmm, I see a few inconsistencies cropping up here. First, we
already have AUTOMAKE_run. It has slightly different syntax.
With your
* Stefano Lattarini wrote on Sat, Oct 10, 2009 at 03:42:52AM CEST:
At Friday 09 October 2009, Ralf Wildenhues wrote:
I'd shorten this to:
Use run_command throughout.
I'd prefer to keep it a bit more verbose. I settled for this:
Use new subroutine run_command instead of hand-crafted
Hello Stefano,
* Stefano Lattarini wrote on Wed, Oct 07, 2009 at 08:01:51PM CEST:
The master branch of the automake Git repository has advanced again
since I submitted the latest version of my patch. In particular, a new
test cases has been added, which required some editing to work smoothly
14 matches
Mail list logo
