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

[Zack Weinberg <zackw at panix dot com>]

On Mon, Jun 12, 2017 at 1:34 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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?
>
> [a number of excellent reasons why we can't do that right now]

I was being a bit tongue-in-cheek here, and I realize we can't get
there immediately, but I really do think "no generated files
whatsoever in source control" is a desirable goal to strive for in the
long term.  No checked-in files generated by autoconf, in particular,
I think should be relatively easy.  (Obviously not for 2.26.)

To some of your specific points ...

> 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.)

autoconf's insistence on writing files into the source tree, and
having the main "configure" script be located at the top of the source
tree, is somewhat unfortunate, yes.

However, for this use case, it should be good enough to check out the
tree, run autoreconf, and _then_ mark the source tree read-only.  If
we can't make a single invocation of autoreconf do everything that's
needed, that would be another bug to fix.

(I entirely agree that .mo files should be generated in the build directory.)

> 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.

This is a big headache, yeah.  Automake makes you list in the
makefiles every single file that belongs in the distribution, which is
a pain.  On the other hand, it means that "make dist" works _from_ a
tarball release, which can be useful (e.g. unpack a tarball and run
"make dist", you should get another bit-identical tarball, or
something is horribly wrong).

A third way might be to rely on git for the things that are checked
in, but the makefiles for generated files that need to be in a tarball
release.

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

I tend to think that == dependencies on tools should automatically be
considered bugs.  >= dependencies are OK, and I am actually fine with
requiring bleeding-edge tools for working with a git checkout (as
opposed to building a release).  I don't see a lot of value in
facilitating _development_ in old LTS-type environments.

> 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).

These are expectations for the math functions, computed with an
independent, extra-high-precision implementation, right?

It might make sense to maintain these separately from the glibc
repository.  You could test _any_ math library with them, after all?
I'd still structure that repo with no generated files checked in on
master, but have an alternative trunk that _just_ contained the
generated expectations, with parallel tags.  Then glibc could pull
that in as a submodule as appropriate.  (Or something like that.  Just
thinking out loud here.)

> 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.

For requiring more tools to build from _releases_, we need to think
more carefully about available tools in old LTS-type environments.
python3 strikes me as the most likely to be trouble, which is
unfortunate, because I really want that one. :)  But I agree with the
principles here.

zw