Re: Automated Toolchain Building and Testing

2013-08-28 Thread Samuel Mi 
On Thu, Aug 29, 2013 at 2:54 AM, Jan-Benedict Glaw  wrote:
> On Thu, 2013-08-29 02:43:54 +0800, Samuel Mi  wrote:
>> > ...or can you, instead of using the Java-based
>> > client part of Jenkins, issue all commands over a SSH (or maybe even
>> > Telnet...) session?  Is there a module for this available?
>> If making jenkins running on target systems you want whether old or
>> modern, then take a look at Jenkins-SSH
>> (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH) to remotely
>> control over ssh.
>
> This looks like a SSH connector for the Jenkins server side, no?
No. Actually, Jenkins implements a built-in SSH server within itself.
At this point, it's consider to be a normal SSH server. So, you can
remotely access Jenkins server via SSH after setting up corresponding
configurations within it.

Re: Automated Toolchain Building and Testing

2013-08-28 Thread Samuel Mi 
> I'm not too sure if Jenkins is actually a good choice, just because I
> question that there's a working Java especially for old Unix-alike
> systems that GCC still (in theory) supports. What about eg. older IRIX
> or Ultrix systems?
I have no such experience on running jenkins under java runtime on old
and legacy systems. In my case, it's exactly focused on such
environment which is with modern linux-like systems like Ubuntu. plus,
the minimum runtime environment of running jenkins with up-to-date
version is java 1.5 or later.

> ...or can you, instead of using the Java-based
> client part of Jenkins, issue all commands over a SSH (or maybe even
> Telnet...) session?  Is there a module for this available?
If making jenkins running on target systems you want whether old or
modern, then take a look at Jenkins-SSH
(https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH) to remotely
control over ssh.

Re: Automated Toolchain Building and Testing

2013-08-28 Thread Samuel Mi 
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  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  jbg...@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".