This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Patch 2 of 2 for ILP32 aarch64
On Mon, 12 Jun 2017, Zack Weinberg wrote:
> On Mon, Jun 12, 2017 at 12:44 PM, Andreas Schwab <firstname.lastname@example.org> wrote:
> > On Jun 12 2017, Steve Ellcey <email@example.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
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