On Sunday 16 January 2011, Ralf Wildenhues wrote:
> Hello Stefano,
>
> * Stefano Lattarini wrote on Sat, Jan 15, 2011 at 04:50:31PM CET:
> > On Saturday 15 January 2011, Ralf Wildenhues wrote:
> > > ensure_distcheck_ ()
> > > {
> > > if $MAKE --version -v | grep GNU; then
> > > $MAKE distcheck
> > > else
> > > :
> > > fi
> > > }
>
> > Hmm... To me, this sounds an awful lot like sweeping the dirt under
> > the rug.
>
> OK, so here's a more open alternative: let's try to fix the failures.
> Are you going to work on this, or at least provide significant help?
>
I might try, but obviously I cannot guarantee anything.
What about the following middle ground solution for the moment: extend
the distcheck target to honor a switch (which should probably be an
environment variable, say 'DISTCHECK_USE_VPATH') telling to perform
simply an in-tree build (while continuing to perform VPATH builds by
default).
This new behaviour would be completely backward-compatible, more
flexible, and wouldn't overly penalize non-GNU makes.
Then we could go with your idea of using `ensure_distcheck_', fixed
as follows:
ensure_weak_distcheck_ ()
{
if $MAKE --version -v | grep GNU; then
$MAKE distcheck ${1+"$@"}
else
env DISTCHECK_USE_VPATH=no $MAKE distcheck ${1+"$@"}
fi
}
WDYT?
> The current amount of failures from this hunting for regressions in
(there should be a "makes" in between "this" and "hunting", right?)
> Automake proper harder than it should be, because there are many
> failures which could be testsuite regressions, or regressions for
> features we don't advertise, or long-standing issues for which it
> thus not imperative that we fix them quickly.
>
> I reject the notion of disallowing VPATH builds with GNU make only.
>
(you meant "allowing" here, I guess)
OK. I myself now think that the middle-ground solution I've proposed
above is better.
> The reason is simple: I make good use of this feature every time I test
> the Automake package with some non-GNU make (I build several platforms
> off of one tree shared via NFS). It would make my testing significantly
> harder if GNU make needed to be added to the mix.
>
> Just diagnosing non-GNU make at configure time in a VPATH setup is
> slightly problematic because many people still do
> ../configure
> gmake
>
> (note the missing MAKE=gmake on the configure command line). Or, as I
> also happen to do, go back to a build tree several months old and do
> 'git pull && cd build && make' in it, forgetting that MAKE=gmake was set
> at configure time (portably warning about this at make time is
> surprisingly hard to do right, when you can't assume GNU make).
>
Points taken.
> > What about a more radical but IMHO more honest approach, to be implemented
> > in four steps:
> >
> > [1] Clearly document in the manual that VPATH builds are expected to
> > work with GNU make only.
>
> See above. For lots of packages, portable make works just fine even in
> VPATH mode. I'm fine with mentioning that GNU make or non-VPATH should
> be tried if there are problems with another make in a VPATH build.
>
> > [2] Update AM_INIT_AUTOMAKE to make it complain(*) if it detects that
> > $MAKE is not GNU make but a VPATH build is being attempted. The
> > user should be allowed to override this check, obviously.
>
> See above.
>
> > (*) With a warning or an error? Not sure yet, but it should be warning
> > in the next Automake version, not to suddenly disrupt backward
> > compatibility.
>
> Generally, I want to keep even git master of Automake always in a
> close-to-releasable state. Even if all current failures are only
> issues in the testsuite, or long-standing bugs, this is too much to
> just ignore it.
>
> Cheers,
> Ralf
>
Regards,
Stefano
