about summary refs log tree commit diff
path: root/manual/conf.texi
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2016-11-11 21:07:08 +0000
committerJoseph Myers <joseph@codesourcery.com>2016-11-11 21:07:08 +0000
commit14f95a420313ee745b80fe71a0fe6f61b46b327c (patch)
treedd7f98f333906e6a2e5e5779dabf5a9c8680c98c /manual/conf.texi
parent84c426b85db7cc595f8c5d3ec549009490ca6299 (diff)
downloadglibc-14f95a420313ee745b80fe71a0fe6f61b46b327c.tar.gz
glibc-14f95a420313ee745b80fe71a0fe6f61b46b327c.tar.xz
glibc-14f95a420313ee745b80fe71a0fe6f61b46b327c.zip
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first.  It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).

The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once.  It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.

You call the script as

build-many-glibcs.py /some/where thing-to-do <other-arguments>

where /some/where is a working directory for the script.  It will
create and use subdirectories build, install, logs therein.  You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere).  In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components.  You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out.  If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.

Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs.  So you run, in that order:

build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs

host-libraries is run once and then those libraries are used for all
the compilers.  compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs).  You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).

I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).

GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured).  There are various problems for particular configurations
as well.

Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).

	* scripts/build-many-glibcs.py: New file.
Diffstat (limited to 'manual/conf.texi')
0 files changed, 0 insertions, 0 deletions