This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Automated Toolchain Building and Testing
- From: Samuel Mi <samuel dot miing at gmail dot com>
- To: Jan-Benedict Glaw <jbglaw at lug-owl dot de>
- Cc: binutils at sourceware dot org, gcc at gcc dot gnu dot org, David Edelsohn <dje dot gcc at gmail dot com>, Diego Novillo <dnovillo at google dot com>, Gerald Pfeifer <gerald at pfeifer dot com>
- Date: Wed, 28 Aug 2013 23:26:29 +0800
- Subject: Re: Automated Toolchain Building and Testing
- Authentication-results: sourceware.org; auth=none
- References: <20130827195417 dot GA29134 at lug-owl dot de>
Hi Jan,
Looks like you for now have been trying to find out a solution
suitable for you to automatically build GCC from source combined with
certain continuous systems like Jenkins. As a matter of fact, Jenkins
is exactly a good choice to do such thing just mentioned, due to
itself with so many plugins[1] you can pick up to fit your needs.
In addition, there is a instance of jenkins out there used to nightly
build toolchain[2] as a good starting point for you to setup such a CI
(Continuous Integration) infrastructure.
References:
[1] https://wiki.jenkins-ci.org/display/JENKINS/Plugins
[2] https://android-build.linaro.org/jenkins/view/Toolchain/
Yours truly,
Samuel
On Wed, Aug 28, 2013 at 3:54 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> Hi!
>
> My first try on a build robot (http://toolchain.lug-owl.de/buildbot/
> and http://toolchain.lug-owl.de/buildbot/timeline.php) is running for
> some time now, so I'd like to do a next step.
>
> (The current homegrown build script is designed to do a
> cross-build with a named --target and no --build/--host, building
> binutils, gold, gdb and stace1 gcc. The testsuite isn't run as of
> now. And since this isn't a full bootstrap re-building GCC with
> itself, it's mostly a compatibility check for the toolchain
> sources to build with the detected system C compiler.)
>
> While the current setup works quite fine, it's time to extend it to
> (as a minimum) run the test suite and report on it. As people
> suggested, I had at some other Continuous Integration systems, mostly
> Jenkins and BuildBot. Both share a common problem: They require extra
> software on a given build slave to work. (Jenkins expects a working
> Java installation, BuildBot needs Python and Twisted.) Without having
> checked this, I guess that other CI systems impose similar
> dependencies.
>
> At this point, I'd like to get some feedback from you! Do you have
> any CI system running that only needs eg. ssh to log-in into a slave
> box? Do you think that it's acceptable for a Toolchain Build Robot to
> require Python/Twisted or Java on a slave system? I'm thinking about
> some of the more obscure systems (m68k-netbsd, ...) that probably
> won't have Java readily running. And even gcj may not be ported to
> all systems that otherwise could run a Build Robot slave instance.
>
> The decision thus is like this: Continue to run some self-written CI
> system that fits our needs and specifically covers the rarely-used
> platforms? Or run one with well-known software, though we'll probably
> loose obscure systems?
>
> MfG, JBG
>
> --
> Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
> Signature of: "really soon now": an unspecified period of time, likly to
> the second : be greater than any reasonable definition
> of "soon".