A recent build-many-glibcs.py build
<https://sourceware.org/ml/libc-testresults/2017-q1/msg00067.html> ran
into what proves to be an old known bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980> with parallel
install of GCC (one which as discussed there might require automake
changes to fix).  This patch makes build-many-glibcs.py avoid such
intermittent failures from parallel install by using -j1 for GCC make
install (the code in question also applies to binutils make install,
but it doesn't seem worth trying to avoid -j1 there; the builds and
installs of different toolchains are still fully parallel with each
other, this is only about the case when there are few enough of those
that multiple jobs can get used within a single make install).

	* scripts/build-many-glibcs.py (Config.build_cross_tool): Use -j1
	for make install.

I used this patch to run the new build script with python3.2, it may be worth
adding this hack if python3.5 is not widespread (might work with older python,
i haven't tested that).

This patch make build-many-glibcs.py work with python 3.2 by
adding fallback implementation to python 3.5 facilities if they
are not present.

Checked building a x86_64-linux-gnu toolchain with python 3.2.

2016-11-22  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	* scripts/build-many-glibcs.py (os.cpu_count): Add compatibility definition.
	(re.fullmatch, subprocess.run): Likewise.

The 32-bit powerpc configurations in build-many-glibcs.py were failing
to cover the powerpc32 multiarch code at all, because that code is
only built for power4 and above configurations.  This patch adds a
32-bit power4 configuration so that at least some of that multiarch
code gets build-tested.  (This is preparation for reviewing the w_*
file renaming, which affects such powerpc32 multiarch files.)

	* scripts/build-many-glibcs.py (Context.add_all_configs): Add
	power4 glibc for powerpc-linux-gnu.

Now that a release branch exists for binutils 2.28, this patch makes
build-many-glibcs.py use that by default in place of 2.27.

	* scripts/build-many-glibcs.py (Context.checkout): Default
	binutils version to 2.28 branch.

When build-many-glibcs.py re-execs itself with execv, any buffered
output on stdout may be lost (in particular, messages intended to go
to a bot's log about the re-exec taking place).  This patch makes it
flush stdout before execv, similar to the flush before running a
subprocess from the bot that is done to ensure output appears in the
right order.

	* scripts/build-many-glibcs.py (Context.exec_self): Flush stdout
	before calling execv.

This patch updates build-many-glibcs.py to use Linux 4.9 for kernel
headers unless another version is explicitly specified.  Note that
when a version changes like this you'll need to use --replace-sources
when updating an existing checkout to tell build-many-glibcs.py it's
OK to delete and replace the sources of a component for which the
version used has changed.

	* scripts/build-many-glibcs.py (Context.checkout): Default Linux
	kernel version to 4.9.

This patch adds a --strip option to build-many-glibcs.py, to make it
strip the installed shared libraries after installation.  This is for
convenience if you want to compare installed stripped shared libraries
before and after a patch that was not meant to result in any code
changes: you can run with this option, copy the install/glibcs
directory, run again with the patch and compare the */lib*
subdirectory contents.

(It might make sense for the option to strip libraries in other
directories, including stripping debug information from static
libraries, with a view to making it possible for a
no-generated-code-changes patch to result in completely identical
install/glibcs directories, so simplifying comparison, though that may
need other build determinism changes, e.g. to build deterministic .a
files.)

	* scripts/build-many-glibcs.py (Context.__init__): Take strip
	argument.
	(Glibc.build_glibc): Strip installed shared libraries if
	requested.
	(get_parser): Add --strip option.
	(main): Update Context call.

This patch makes build-many-glibcs.py support a "bot" action, for
repeatedly running a checkout and build cycle.

Two new configuration variables are used in bot-config.json.  "delay"
indicates the time to sleep after each bot-cycle round (regardless of
whether that round actually ran any builds); "run" is a boolean, which
is false if the bot should just exit (the point of this is that you
can edit bot-config.json to set this to false to cause a running bot
to exit cleanly between builds) and true if the bot should run.  The
bot does not exit if the bot-cycle process exits with error status
(that can occur when sourceware's load limiting means anonymous
version control access fails, for example), just sleeps until it's
time to try again.

The script is changed to flush stdout before running a subprocess in
bot-cycle, so that when output is redirected (as expected for a bot)
the status messages from bot-cycle appear in their proper position in
its redirected output relative to the output from the subprocesses
run, and to copy the logs directory before running builds in bot-cycle
so that the logs from at least one complete build are always available
for looking at how something failed, even while the next build is
running.

	* scripts/build-many-glibcs.py: Add bot to usage message.  Import
	time module.
	(Context.__init__): Initialize self.logsdir_old.
	(Context.run_builds): Handle bot action.
	(Context.bot_cycle): Copy logs directory before running builds.
	(Context.bot_run_self): Take argument for whether to check
	subprocess result.  Flush stdout before running subprocess.
	(Context.bot): New function.
	(get_parser): Allow bot action.

This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script.  When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds.  Email is sent with the results of the build (for
each build action done).

The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component.  If the script has changed, rebuild
everything.  If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.

Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py.  It might contain
e.g.

{
  "compilers-rebuild-delay": 604800,
  "email-from": "Example Name <user@example.org>",
  "email-server": "localhost",
  "email-subject": "GCC 6 %(action)s %(build-time)s build results",
  "email-to": "libc-testresults@sourceware.org"
}

My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json.  Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).

	* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
	Import email.mime.text, email.utils and smtplib modules.
	(Context.__init__): Initialize self.bot_config_json.
	(Context.run_builds): Handle bot-cycle action.
	(Context.load_bot_config_json): New function.
	(Context.part_build_old): Likewise.
	(Context.bot_cycle): Likewise.
	(Context.bot_build_mail): Likewise.
	(Context.bot_run_self): Likewise.
	(get_parser): Allow bot-cycle action.