[haiku-development] Re: [Haiku Project] [GSoC Idea] Buildbot for Haiku
- From: Matt Madia <mattmadia@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 25 Mar 2011 00:09:29 +0000
On Thu, Mar 24, 2011 at 08:00, Vivek N <mail@xxxxxxxxxxxx> wrote:
> On Thu, Mar 24, 2011 at 1:16 AM, Matt Madia <mattmadia@xxxxxxxxx> wrote:
>> One of my concerns with designing a BuildBot implementation is the logic
>> flow.
>>
>> For example, there's two basic types of host's -- Haiku and not-Haiku.
>> * Haiku hosts rely on using the installed build chain via
>> --cross-tools-prefix.
>> * non-Haiku hosts rely on downloading and compiling the buildtools
>> (buildtools/trunk)
>>
>>
>> It's important to monitor both haiku/trunk *and* buildtools/trunk* for
>> changes.
>> For instance, whenever a change is made to the buildtools,
>> 1. update the local copy of the buildtools
>> 2. all of the generated directories should be deleted
>> 3. compile the buildtools (and being able to catch&report any failures)
>> 4. compile Haiku (and being able to catch&report any failures)
>>
>
> The different specifications for Haiku and non Haiku hosts can be done by
> implementing buildbot slaves and assigning different schedulers and
> builders. Each builder has a build factory which is a series of steps, and
> buildbot provides object wrappers for different tasks such as shell
> commands, downloads, compilation, testing etc. The existing implementation
> has a large number of XML files for configuration. Since parsers are
> provided for most (all?) of the formats, I thought of writing some code
> generators that would generate some buildbot/python configuration code from
> the XML for different objects once the base framework is setup and
> customization of buildbot is done for Haiku's needs.
Originally, it was believed that a decent portion of BuildBot's code
would need to be adjusted with new build steps to account for
monitoring both the buildtools and haiku repository, handling the
different architectures, targets, and other various build options --
eg http://buildbot.net/buildbot/docs/latest/full.html#Writing-New-BuildSteps
If that is not the case, then the amount of actual coding (and
associated time) will be significantly less and the project idea would
definitely need to be paired with other ideas (or at least additional
goals that go beyond merely configuring BuildBot for Haiku's build
system)
* possibly integrating the execution of post-build scripts inside the
final Haiku imagefile.
* possibly other automated tests
* Trac extensions -- eg, to allow ticket maintainers the select
patches to be tested by BuildBot and conditionally committed or to
provide some meaningful feedback
* implement/improve a script to check for coding-style conformance of
patches (and other code)
In short, a simple "Configure BuildBot for Haiku" is expected to be
paired with other tasks or .
... I'll update the ideas page to mention this and maybe even this thread.
> Is there any other way that I can contribute right now?
Preparing a more involved project idea, with more details would be
good. That may take some experimenting with BuildBot and Haiku's
build system. As far as providing a code contribution -- one
possibility is the checkstyle script, which also uses python.
Hope this helps and clears up some details.
--mmadia
Other related posts:
