[kde-freebsd] ensuring KDE svn trunk builds on BSD

[Alexander Neundorf]

On Tuesday 17 November 2009, Raphael Kubo da Costa wrote:
> On Tuesday 17 November 2009 19:38:42 Alexander Neundorf wrote:
> > Hi,
>
> Hey there,
>
> > I'm looking for people who are interested in providing Nightly builds of
> >  KDE 4 svn trunk for Solaris.
> > Recently we set up cdash dashboards for several KDE modules (kdesupport,
> > kdelibs, kdebase, kdepimlibs, kdepim, kdenetwork, kdeadmin,
> > kdeaccessibility , kdeexamples) on http://my.cdash.org.
> >
> > The idea is to build KDE every night on different machines and operating
> > systems to make sure it stays building everywhere.
> > If something breaks, notification emails with the errors can be sent,
> > e.g. to this list or to the committers.
> >
> > Until now only me and Volker Krause are providing Nightly builds there,
> > and both on Linux. Now most KDE developers are using Linux, so having
> > Nightly builds on non-Linux systems is actually even more important.
> >
> > So, is anybody here interested to run a Nightly build of KDE on
> > Free/Net/OpenBSD once per day ?
>
> I'm interested in doing that, as every once in a while I try to compile
> trunk and make sure it runs at least on FreeBSD. I believe the FreeBSD team
> has something like that for their ports (tinderbox, for example), but that
> only compiles the stable releases.
>
> Dear porters (fluffy, tabthorpe, miwi etc), do you have any opinion on
> this?
>
> Alex, do you think it would be somehow useful for the porters team as well
> (porters == packagers) or does it only make sense for KDE developers to
> make sure trunk compiles smoothly?

Not sure about the porters/packagers.
The purpose is to make sure that the code keeps building on the platform every 
day. If something breaks, either the developer is notified directly or e.g. 
this list is notified and then you can either fix it or try to bother the 
respective developer so long until he fixes it again.

> > I still have to document this somewhere, probably on techbase, on how to
> >  get this working.
> > Short version: check out kdesdk/, there in cmake/scripts/ is a shell
> > script Nightlys-2.6.2, which is the shell script which drives the Nightly
> > build on my machine. If you open it, the places which have to be changed
> > should be obvious, i.e. the path to cmake, setting CMAKE_PREFIX_PATH, and
> > not that much more.
> >
> > So, if you are interested, please let me know and I'll help with setting
> > it up.
> > The first step should probably be that you head over to my.cdash.org and
> >  get yourself an account there.
>
> Well, I'm interested in helping. What are the next steps?

* Go to my.cdash.org and get an account.
* Subscribe to the projects you're interested in (should start with kdesupport 
and kdelibs)

* For every module you run a Nightly build for, you need a checkout. This 
checkout provides the ctest-script which drives the actual Nightly build 
(e.g. KDESupportNightly.cmake). During the Nightly build then in an 
additional location the source will be checked out and built (~/Dashboards/ 
if you don't specifiy something else explicitely).

* Get the KDECTestNightly.cmake file from kdesdk and put it somewhere: 
http://websvn.kde.org/trunk/KDE/kdesdk/cmake/modules/KDECTestNightly.cmake?view=log


* Get the Nightlys-2.6.2 script from kdesdk: 
http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/Nightlys-2.6.2?revision=1049181&view=markup
Have a look at it, I think it is obvious what needs to be changed for your 
system. I'd say for the beginning you should try to get kdesupport and 
kdelibs  working.

What you need to adapt:
CTEST (obviously)
KDECTESTNIGHTLY_DIR - must point to the directory which contains the file
                      KDECTestNightly.cmake
SUFFIX  - this will be appended to the name of the build on my.cdash.org. 
          That name will start with the operating system, and then the suffix
          appended.
CMAKE_PREFIX_PATH - this env.var. is used by cmake in the find_program(),
                    find_library(), find_file() and find_path() commands. It 
can contain a list of directory, and e.g. for find_library(), each of these 
directories will be checked for the library which is searched by appending 
lib/ to it (and include/ for find_path()/find_file() and bin/ for 
find_program()).
So, set CMAKE_PREFIX_PATH so that it points to all the base install 
directories of software packages which are required by KDE4 and which are not 
in the default places (like /usr, /usr/local, /opt).
Then, after building and installing kdesupport, append the kdesupport install 
dir to it, after building and installing kdelibs append the kdelibs install 
dir to it etc.. It is important that each module is installed into its own 
install dir, so we notice if some other module doesn't use the correct 
include dirs/link dirs.

After adjusting this, just run the script and see what happens (it should 
build, test and submit to my.cdash.org).

Alex