Summary from Buildsystem BoF at Desktop Summit

[henry7638@gmail.com]

Very interesting, but it appears to assume all the world is linux x86 (these days probably x86-64, but the such VMs wouldn't run on any 32 bit machines that might be left). Many of our big problems are things that work fine there, but months latter someone gets around to doing that config on: ARM, PPC, or some more obscure processor; or it doesn't work on xBSD, Microsoft Windows, MacOSX, or one of the more obscure OSes we support. 

As such, I ask that everyone working on build systems consider how their solution can scale out to those combinations?  There are copyright problems with Comercial OSes (but windows machines are easy to find - thus a vm may not be ideal despite the simplicity of it)

Volker Krause <vkrause at kde.org> wrote:

>On Monday 15 August 2011 23:31:26 Alexander Neundorf wrote:
>> -----------------------------------------
>> 8) Testing
>> -----------------------------------------
>> 
>> We shortly discussed testing, continuous builds and nightly builds.
>> I hope Volker (or somebody) can write a better summary.
>> Volker has a prototype for easily running VM-based builds on
>Linux-machines,
>> which contribute their results to a cdash dashboard.
>> Marcus introduced us to cdash at home, which has a similar purpose, i.e.
>make
>> it very easy for people to contribute their machine as a
>continuous-build
>> host to a project.
>> It seems there is growing interest in establishing structured testing
>for
>> KDE, also highlighted by Till's talk "The limits of portability".
>> More details to come...
>
>ok, so let me explain what I have been working on there.
>
>The idea we came up with in Randa basically is to deploy more or less
>blank 
>Linux VMs in a SETI at Home-style to as many as possible machines. They 
>continuously run kdesrc-build with enabled CDash reporting as well as a
>script 
>to install new dependencies. All those scripts are regularly updated
>from Git, 
>allowing us to deploy updates to all VMs out there. The only exception
>is the 
>kdesrc-build config file, which is provided by a central server and
>downloaded 
>before every build run. This allows us to distribute different build 
>configurations to all VMs. Right now this config files simply
>randomized on a 
>number of parameters, giving us full coverage with a high probability
>over 
>time (with the time depending on the number of active VMs).
>
>This approach addresses one specific problem of the entire CI topic,
>namely 
>testing as many as possible of the various different build options we
>have 
>(platform profiles, debug vs. release, different dependency versions,
>with or 
>without optional dependencies, etc). This does not address testing on 
>different OS/platforms etc., so it's only one piece in the puzzle, not
>the 
>single solution.
>
>"Code" is in kde:scratch/vkrause/crowdci, the VM is created with SUSE
>Studio: 
>http://susegallery.com/a/8ECjUa/kde-crowdci. It still has some blocker
>bugs 
>that prevent it from installing extra dependencies without rebooting,
>so it 
>doesn't get past kdelibs yet, once that is fixed we can do a test
>deployment 
>and see if the approach works as intended. Help is of course welcome :)
>
>regards
>Volker

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.