[ Adding automake to CC: ]
On Saturday 15 January 2011, Ralf Wildenhues wrote:
> OK, so all the added '$MAKE distcheck' "for safety" at the end of the
> tests caused roughly a thousand new test failures across the board, it
> seems, drowning other signals. Most of these failures apparently have
> two reasons:
>
> 1) Cleanup failed to remove some directory because of stale NFS handles,
>
> 2) The native make is not up to the task of VPATH builds.
>
> Now, distcheck is not a GCS-mandated target, so it need not work
> everywhere. Also, we already document in the GNU-global INSTALL file
> that GNU make is preferred when doing VPATH builds (although Automake
> currently still does try to work around all issues except those from
> Solaris 2.6 and IRIX make for the standard targets).
>
> So, how about changing *those* $MAKE distcheck invocations which don't
> have added value over "checking that the distribution is complete" to
> call ensure_distcheck_, with this in defs.in:
>
> ensure_distcheck_ ()
> {
> if $MAKE --version -v | grep GNU; then
> $MAKE distcheck
> else
> :
> fi
> }
>
> (not turning the test result into a SKIP since this is not a major point
> of the test).
>
> Remains only the task to identify for which tests this is true.
>
Hmm... To me, this sounds an awful lot like sweeping the dirt under
the rug.
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.
[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.
(*) 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.
[3] Update "make distcheck" to attempt a VPATH build only with GNU make
(otherwise, an in-tree build should be attempted). Again, the user
should be allowed to easily force a VPATH build if he wants to. The
role/implementation of the "distcleancheck" target might be somewhat
complicated by this.
[4] Fix testsuite fallout, and update/extend the testsuite as
appropriate.
Opinions?
>
> Addressing (1) right may turn out to be more tricky: if there are files
> which are held open by some process, then that would probably be a bug
> in the test. Otherwise, I'm suspecting bugs in the NFS implementation.
> Maybe some of the clean rules are lacking '-' prefix (to ignore return
> status), but that should only be added for those rules where we really
> cannot miss an important failure (e.g., bug in the rule) that we must
> address.
>
This is a separate issue (and anyway I'm pretty ignorant about NFS), so
I'll leave it to another thread.
> Thanks,
> Ralf
>
Regards,
Stefano
