Re: Avoid VPATH-related distcheck failures with non-GNU make

[Stefano Lattarini]

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