new scripts to drive nightly builds available, please try

Alexander Neundorf neundorf at kde.org
Tue May 4 19:42:26 CEST 2010


On Tuesday 04 May 2010, Volker Krause wrote:
> On Monday 03 May 2010 21:46:36 Alexander Neundorf wrote:
> > On Monday 03 May 2010, Volker Krause wrote:
> > > On Sunday 02 May 2010 14:26:56 Alexander Neundorf wrote:
> > > > On Sunday 02 May 2010, Volker Krause wrote:
> > > > > My Linux build still runs on a simple shell script, my
> > > > > Windows/mingw build
> > > >
> > > > Can you post that script here ?
> > > > I'd like to have a look at it.
> > >
> > > attached, but rather boring and relies heavily on macros in my .bashrc
> > > ;)
> >
> > No, not boring. Thanks :-)
> >
> > > > > [1] It would be nice if it would be possible to pass additional
> > > > > arguments to ctest when using e.g. make Experimental in some way.
> > > > > In our case we
> > > >
> > > > In which case do you need "make Experimental" ?
> > > > This just builds what you currently have on your disk.
> > >
> > > I used make Experimental just as an example, I guess we eventually want
> > > Continuous instead in this case. But since the goal is
> > > minimal-intrusive integration into an existing system, it'll need some
> > > adjustments (such as printing the full logs and not doing svn up for
> > > example).
> >
> > Why shouldn't it do svn up ?
> >
> > If I understand correctly how ctest and cdash work together, I think if
> > ctest doesn't do this, then cdash is not able to send the notification
> > emails (because it receives the update information via ctest).
>
> right, that's how it works idealy in my understanding as well. But as I
> said the goal here is minimal intrusive integration of cdash reporting into
> an existing continous package building system. This already does a svn
> checkout of a specific version and thus would not want anything messing
> around with that. The build itself is driven by the usual Debian package
> building tools, which limits our possibilities of injecting ctest calls for
> that as well. Certainly not perfect, but IMHO just build results (no update
> and test) are still better than nothing, especially when run more or less
> continously on a clean system for two architectures :)
>
> This of course does not replace "real" ctest builds, but it allows us to
> collect results of already existing automatic builds in a central place.

When I discussed this with Bill the last time he suggested to actually 
*remove* the "Nightly" and "Continuous" targets from the generated makefiles, 
since they just don't do that. "make Experimental" is ok, the other two don't 
make sense to be run manually from some build tree, Nightly and Cont. builds 
really should be executed from a source+build tree combination which has been 
checked out just for that purpose.

So, the only thing you can do with this kind of setup are Experimental builds, 
without notification emails etc. 
What are the chances to add support for cmake+ctest to the debian tools ? IMO 
this would definitely be the way to go.
I mean, don't they just have to run "ctest -S scriptfile" ?
If necessary, maybe also something could be added to cmake/ctest to be usable 
with the debian tools.

Alex


More information about the Kde-buildsystem mailing list