Buildfarm build_test script on an embedded device.

Christopher R. Hertel crh at ubiqx.mn.org
Wed Oct 5 10:55:07 MDT 2011


Terrance Hutchinson wrote:
> I know I am knew to this list but I just have a question so if it's documented somewhere just point me there and I'll leave you alone.

Welcome.

> In a typical build environment for embedded devices, most development happens on a host and cross-compiled for the target device. No one would ever dream of Compiling on the target device.

True, but once again even the Dockstar is a fairly competent little device.
 It has low RAM, and only an ARMv5 processor, but when I compare it against
the platforms I used when I first started working on Samba in the 90's it's
actually quite powerful.

I do think it is worth-while to separate out the two aspects of these tests,
however.  That, I believe, is what some of the others on this thread are
trying to point out.  The Build Farm tests are testing first for the ability
to build on a particular target platform (OS, Distribution, Hardware).

One problem with the idea of compiling on Arch-Linux for x86 or x86-64 is
that the Arch-Linux-ARM distribution is *based upon* regular Arch-Linux, but
it isn't really the same.  I'm going to try running regular Arch on an Atom
processor box I have.  If that works, I'll submit it for consideration as a
Build Farm member.

> Is there a specific reason to be compiling on the target device?

Well...  It does compile, it just takes a while.  That's why it would be
useful to separate out the build from the run-time tests.

I've not ever set up cross-compilation; it just seemed easier to compile
natively.

> From what I gather it is the tests, couldn't the tests be broken out for these specific platforms?

Yes, that's one of the things I am suggesting that the "embedded"
enthusiasts, such as myself, consider.

> I am just curious. I think that if it's possible, separating the test from compilation might address these compile issues. Like Michael said, a host running a cross-compiler but then have it push the finished code to the target for testing.
> 
> This is just an idea. Feel free to shoot it down :).

Perfectly rational idea.  It's just that it wouldn't work in the Build Farm,
as the Build Farm is configured today, since the standard build_test script
does combine both aspects.

Chris -)-----

> Thanks,
> Terrance
> 
> -----Original Message-----
> From: samba-technical-bounces at lists.samba.org [mailto:samba-technical-bounces at lists.samba.org] On Behalf Of Michael Wood
> Sent: Wednesday, October 05, 2011 9:55 AM
> To: Christopher R. Hertel
> Cc: samba-technical at lists.samba.org; Andrew Bartlett
> Subject: Re: Buildfarm build_test script on an embedded device.
> 
> On 5 October 2011 17:47, Christopher R. Hertel <crh at ubiqx.mn.org> wrote:
>> Some notes, as we consider how we will move forward with Embedded Samba.
>>
>> Matthieu's changes to the build_test script reduced the run time by 
>> only two hours.  That, again, emphasizes the point that it's likely 
>> the code build itself that is taking too long.
> [...]
> 
> Probably obvious questions, but anyway:
> 
> Would a bunch of machines, distcc and make -j help with this at all? :)
> 
> Or maybe a powerful x86 box running a cross compiler and distcc.
> 
> --
> Michael Wood <esiotrot at gmail.com>

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org


More information about the samba-technical mailing list