Re: Use gen-libm-test.py to generate ulps table for manual

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 13 Aug 2018, Andreas Schwab wrote:

> On Aug 09 2018, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> > patch.)  Note that this introduces a Python dependency for building
> > the manual, which is thus noted in install.texi and NEWS.
> 
> This would add python to the bootstrap cycle which is a big problem.

Why is it a big problem?  I'd expect it to be at most a one-off addition 
to an automated bootstrap process.

(a) If you are bootstrapping purely from sources and a minimum set of 
binaries (e.g. starting from GNU Mes), e.g. to defend against Thompson 
attacks, you'll inevitably need various techniques to break cycles.  In 
this case it's very simple: an early glibc build might not build the 
manual (or run tests, etc.), but once Python has been built a full glibc 
build can build the manual and run tests.  Even with Python required for 
the build, such a bootstrap from a minimum set of binaries would probably 
in practice need to start with building older, simpler versions of various 
tools with reduced dependencies (GNU Mes does).

(b) If you are bootstrapping a new architecture by cross-compilation, (i) 
Python on the build system is fully sufficient for building the 
cross-compiled glibc including its manual, and (ii) either you can 
cross-compile Python, or you can build it natively later.

(c) If you are repeatedly rebuilding packages with themselves - in the 
full configuration building everything from those packages intended to be 
in a release - to ensure the rebuilds converge to a set of binary packages 
that are byte-for-byte reproducible when rebuilt with themselves (a 
stronger version of reproducible builds than the ones where reproducibly 
building package X in a release depends on having an older version of 
package Y than the one included in that release), it doesn't even affect 
the set of packages that depend on each other because Python is already 
used in glibc testing.

For both (a) and (b), having automation of the bootstrap process is 
clearly strongly desirable, and maybe a one-off change to that automation 
would be needed to insert a few extra builds.  For (c) I'd expect existing 
automation to be able to work automatically with the build-dependencies so 
only those need updating for it to determine the updated set of packages 
to rebuild (and as noted, Python is already a dependency for running the 
full set of tests).

There was clear support in the discussion descending from 
<https://sourceware.org/ml/libc-alpha/2018-07/msg00549.html> for replacing 
both perl and awk code in the build with python for the reasons described 
at <https://sourceware.org/ml/libc-alpha/2018-07/msg00559.html>: it's now 
better for the current community maintaining glibc.  For the bootstrap 
cases discussed, I don't think Python is significantly different from any 
other widely-available build dependency - glibc is very careful about 
cyclic build dependencies in the actual cross-toolchain bootstrap for (b) 
(glibc built with a static-libgcc-only C-only GCC should be identical to 
one built in a cycle iterated more times, although you need to rebuild 
glibc with the shared-libgcc C++-supporting GCC to get a build tree 
appropriately configured to run the tests), but for tools that only need 
to be present on the build system to build glibc (not to be built 
specially for the glibc architecture), and where there aren't strong 
dependencies on particular versions, I think such bootstrap considerations 
are really matters for other projects not for glibc.

-- 
Joseph S. Myers
joseph@codesourcery.com