autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Avoid certain spurious `testsuite' rebuilds


From: Ralf Wildenhues
Subject: Re: Avoid certain spurious `testsuite' rebuilds
Date: Mon, 10 Apr 2006 14:41:38 +0200
User-agent: Mutt/1.5.11

Hi Stepan,

* Stepan Kasal wrote on Mon, Apr 10, 2006 at 01:57:14PM CEST:
> On Mon, Apr 10, 2006 at 01:40:30PM +0200, Ralf Wildenhues wrote:
> > * Stepan Kasal wrote on Mon, Apr 10, 2006 at 11:40:33AM CEST:
> > >  1) mktests.sh is no longer a maintainer tool, thus 
> > > $(TESTSUITE_GENERATED_AT)
> > >     are no longer distributed,
> 
> > > I understand that mktests.sh is no longer considered maintainer-only, so 
> > > this
> > > should be OK.
> > 
> > Dangerous.  I don't like this much.
> 
> well, in a sense it is dangerous to build anything on user's machine.

This is a broad statement.  Experience with anything in Autoconf shows
that it takes a long time to produce something truly portable.  So now
we're trying to make mktests.sh portable in a few weeks; I'm trying to
say it's an illusion to assume that we're done _right now_.  When a few
months have passed after any more changes were necessary, then you may
rightly claim this.  But not after two weeks that have seen an almost
complete rewrite of it.

And even more so when, at a glance, one can find more potential issues.
What, for example, about the two occurrences of `trap 0'?  Are they
portable?  Wouldn't it have to be 
  trap '' 0
instead, as the manual suggests because of the thread referenced in
http://lists.gnu.org/archive/html/autoconf-patches/2006-01/msg00040.html
even if we don't know whether there's a shell where it fails?

So we overlooked that until now; how do we dare claim that it's portable
immediately after fixing this one?

Furthermore, it's always helpful to make oneself aware that a certain
part of applied changes introduce new bugs, whether you like it or not;
and it's this amount I'm trying to minimize.  That's what stabilization
is all about, and that's why I'm trying to rigorously reject anything
that changes more than necessary.

> This change simplifies tests/Makefile.am, so I tend to like it.

This statement is a direct argument to skip this for 2.60: no
simplifications now, only actual bug fixes.

> The prerequisite is a portable implementation of mktests.sh, which is
> doable.

Yes.  Given enough time.

> > I don't like a genuine target name that ends in `.tmp' much, to be
> > honest.
> 
> And what about ``testsuite.new''?

That's better.

> > > Moreover I made the change discussed elsewhere that mktests.sh should
> > > fail in the created *.at file happens to be empty.
> > 
> > You forgot to adjust the part in the trap.
> 
> I thought that the trap code is OK (it is triggered by the `exit 1').
> What have I missed.

The trap code touches several files.  Isn't that wrong for them to have
new time stamps in the error case?

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]