Add buildbot tools and config include files.

[wxWidgets.git] / build / buildbot / config / example.xml

<?xml version="1.0" encoding="utf-8"?>

<!--
    Name:       example.xml
    Purpose:    Buildbot example configuration.
    Author:     Mike Wetherell
    RCS-ID:     $Id$
    Copyright:  (c) 2007 Mike Wetherell
    Licence:    wxWidgets licence

    There is one xml file such as this per build slave containing a <build>
    element for each build the slave runs. Each <build> corresponds to a
    column in the waterfall display.

    For full documentation see:
    http://www.wxwidgets.org/wiki/index.php/Development:_Buildbot
-->

<bot xmlns:xi="http://www.w3.org/2001/XInclude"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     xmlns:exsl="http://exslt.org/common"
     xsl:version="1.0">

<!--
    Common declarations.
-->
<xi:include href="include.xml" xpointer="xpointer(*/*)"/>

<!--
    Notes:

    The elements marked 'Unique' below must be unique across all builds on
    all slaves.

    If a build is currently failing because of something other than a bug in
    wxWidgets, e.g. out of space or missing libs, then comment it out, or
    add '** Ignore **' to the beginning of the <name>, so that wxWidgets
    developers know not to waste time investigating.
-->
<build>
    <!--
        Unique. Appears as the title in the waterfall display.
    -->
    <name>Linux x86_64 wxGTK Stable</name>

    <!--
        Unique. The name of a directory for the bulid. On most slaves must
        be a single name, on the Testdrive builds it must be a path such as
        '/tmp/wx/td_gtk'.
    -->
    <builddir>example_gtk</builddir>

    <!--
        The name of a scheduler that will trigger this build. The schedulers
        are usually defined in common.xml, look in there to see if there is
        already one you can use, and add a new one if not.

        The 'trunk_quick' and 'stable_quick' schedulers currently in
        common.xml trigger a build after every source change on the trunk
        and stable branches respectively. There are also daily and weekly
        schedulers 'daily_6am', 'monday_6am', 'tuesday_6am' and so on.

        The <scheduler> element can be omitted, in which case the build
        never runs automatically, but can still be triggered manually.
        Or you can use several, e.g. you could use two weekly schedulers
        that fire on different days to have a build run twice a week.
    -->
    <scheduler>trunk_quick</scheduler>

    <!--
        The meaning of <sandbox> is specific to the build slave. There
        should be a comment in the slave's configuration file saying if they
        are allowed or required. On the testdrive it specifies the remote
        machine that will run the bulid.
    -->
    <sandbox>debug</sandbox>

    <!--
        You can override the make command the compile steps will use using
        this <make> element, if omitted defaults to 'make'. For Windows
        builds this becomes the place to put build options as there is no
        configure step.
    -->
    <make>nmake -f makefile.vc SHARED=1 CPPUNIT_CFLAGS=-I\cppunit\include CPPUNIT_LIBS=cppunit.lib</make>

    <!--
        The build steps.
    -->
    <steps>
        <!--
            Check out the sources, by default the trunk branch. Or for a
            particular branch or tag, e.g.:
                <checkout branch="{$STABLE_BRANCH}"/>
                <checkout branch="branches/WX_2_6_BRANCH"/>
        -->
        <checkout/>

        <!--
            A <shellcommand> build step can be used anywhere you need to run
            arbitrary commands not covered by the standard build steps.
            <haltOnFailure/> specifies that the whole build fails if this
            step fails, without it it continues with the next step anyway.
        -->
        <shellcommand>
            <description>setting up</description>
            <descriptionDone>set up</descriptionDone>
            <haltOnFailure/>
            <command>setup-script</command>
        </shellcommand>

        <!--
            Configure. Options and environment variables can be added with
            the 'options' attribute:
                <configure options="-with-foobar CC=cc CXX=CC"/>
            Omitted for Windows builds.
        -->
        <configure/>

        <!--
            Compile the library. For Windows builds use <compile-msw/>
            instead which runs the make command in the 'build\msw'
            subdirectory instead of the wxWidgets root.
        -->
        <compile/>

        <!--
            Compile subdirectories. There is also <compile-contrib/> for
            branches that have contrib.
        -->
        <compile-samples/>
        <compile-utils/>
        <compile-tests/>

        <!--
            Run the test suites. For Windows builds the command to run the
            test suite must be overridden, e.g.:
                <run-tests>
                    <command>PATH=..\lib\vc_dll;%PATH%</command>
                    <command>cd tests</command>
                    <command>vc_msw\test</command>
                    <command>vc_msw\test_gui</command>
                </run-tests>
        -->
        <run-tests/>
    </steps>
</build>

</bot>