Re: [PATCH] Patch 2 of 2 for ILP32 aarch64

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 12 Jun 2017, Zack Weinberg wrote:

> On Mon, Jun 12, 2017 at 12:44 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> > On Jun 12 2017, Steve Ellcey <sellcey@cavium.com> wrote:
> >
> >> (cd sysdeps/unix/sysv/linux/aarch64; autoconf -I../../../../..)
> >> (cd sysdeps/aarch64; autoconf -I../..)
> 
> Wouldn't it be nice if there were no generated files checked into
> version control?

That would mean you can't build from a read-only checkout.  (Which you 
can't now, because of .mo file generation in the source directory, but 
that's bug 14121, which would be good to fix.  Building from read-only 
sources would help make sure nothing writes into the source directory, 
even temporarily, during a build, so that building multiple configurations 
in parallel with the same source directory is safe.)

That would mean "make dist" can no longer use "git archive" and needs 
instead e.g. to construct a clean source directory and generate required 
files there.

That would mean building from a checkout requires a range of tools, in 
precise versions, that are not currently required.

That would make libm testing from a checkout very slow 
(auto-libm-test-out-cacos and auto-libm-test-out-cacosh take about 80 
minutes each to generate on my system; at present, you only care about 
that if you're changing tests for those functions), as well as requiring 
development headers and libraries for an unreleased version of MPC (for an 
mpc_atan bug fix affecting glibc tests).

Now, for particular cases of generated files, without strong version 
requirements or slow generation or needing to be generated to run 
configure, we might consider case by case "require gperf to build glibc" 
or "require bison to build glibc" or (for Unicode data) "require python3 
to build glibc" or (for C-translit.h) "require perl to build glibc", for 
example - if you require it for releases, not just checkouts, you can 
generate the file in the build directory and not affect use of "git 
archive", and in such cases I'd probably think not checking in the 
generated files is an improvement.  I'm more doubtful about it for 
configure scripts or libm tests (or anything else with tight version 
requirements, unusual tools or slow generation).

(In the Unicode data case I think it copies part of the original file and 
edits other parts.  Let's assume it would be changed to have a checked-in 
template file without the automatically generated parts, from which a full 
file gets generated in the build directory which is then installed in 
/usr/share/i18n and used in generating binary locales.)

-- 
Joseph S. Myers
joseph@codesourcery.com