Re: Fix Hurd build with read-only source directory

[Samuel Thibault <samuel dot thibault at ens-lyon dot org>]

Joseph Myers, le mar. 27 nov. 2018 18:12:28 +0000, a ecrit:
> The logic for generating sysdeps/mach/hurd/bits/errno.h involves a
> stamp file and $(move-if-change).
> 
> The temporary file (generated unconditionally) is generated in the
> source directory.  This means that even if
> sysdeps/mach/hurd/bits/errno.h is up to date, and has an up to date
> timestamp, the build will fail if the source directory is read-only.
> Even with a writable source directory, multiple concurrent builds for
> i686-gnu with the same source directory could race to access the
> temporary file (which always has the same name).
> 
> This patch uses the build directory for the temporary file instead to
> avoid those problems.

Right :)

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> (In the case where the file is out of date and
> the temporary file does need to be moved to the source directory, if
> there are multiple concurrent builds for i686-gnu with the same source
> directory, and the source and build directories are on different
> filesystems, it's possible there might still be races replacing the
> file in the source directory, depending on exactly how mv handles such
> cross-filesystem moves.  This is certainly no worse than the present
> situation, where such a case would have races regardless of whether
> the file is out of date or whether different filesystems are in use.)

Indeed. I guess we don't want to care about concurrent builds on
different systems?  A way to make it safer would be to move the file in
two steps: in scripts/move-if-change, after testing for difference, move
to "$2.$$", thus in the same directory but with a name which shouldn't
be getting conflicts, then move from "$2.$$" to "$2", which will have
filesystem-provided atomicity.

In practice, I wouldn't expect people to make parallel builds in a case
where the file needs to be updated.

Samuel