[PD-dev] autotools on MinGW/MSYS
On 2010-09-14 17:42, Hans-Christoph Steiner wrote: i believe the patch i attached to the ticket to solve the problem but have not been able to test on the very platform. ok, i managed to log in, and my patch indeed solves the reported problem. however, there are more issues, coming from parts of the new build system which i never touched. so i would like to discuss them, before i remove them: #1 when building with msys, the new build system includes pd-watchdog unfortunately, the watchdog uses signals and other quite linux specific stuff. i don't know whether this can be ported, and whether this actually make sense. conclusion: i would exclude pd-watchdog from all w32 builds (if people need signals and whatnot, why don't they use an os that has signals and whatnot) #2 when building with msys, the compiler is forced to g++. there are several problems with this: -- the user cannot chose the compiler themselves anymore, as the CC variable is silently ignored and reset to g++ -- no check is done whether there actually is an executable named g++, it is just assumed. this kind of leads autoconf ad absurdum, as we can simply check for a valid c++ compiler if needed. -- most important however: compiling Pd with a c++ compiler can be a bad idea! the Pd source uses C++ keywords (e.g. template is often used). throwing this code onto a c++ compiler leads to errors. conclusion: don't force autoconf to use g++ as the c-compiler, but rather let it choose the right compiler automagically if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner. masdrt IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autotools on MinGW/MSYS
On Sep 15, 2010, at 6:02 AM, IOhannes m zmoelnig wrote: On 2010-09-14 17:42, Hans-Christoph Steiner wrote: i believe the patch i attached to the ticket to solve the problem but have not been able to test on the very platform. ok, i managed to log in, and my patch indeed solves the reported problem. however, there are more issues, coming from parts of the new build system which i never touched. so i would like to discuss them, before i remove them: #1 when building with msys, the new build system includes pd-watchdog unfortunately, the watchdog uses signals and other quite linux specific stuff. i don't know whether this can be ported, and whether this actually make sense. conclusion: i would exclude pd-watchdog from all w32 builds (if people need signals and whatnot, why don't they use an os that has signals and whatnot) I am pretty sure that Cygwin has signals, so pd-watchdog should just be removed for MinGW/Windows builds. #2 when building with msys, the compiler is forced to g++. there are several problems with this: -- the user cannot chose the compiler themselves anymore, as the CC variable is silently ignored and reset to g++ -- no check is done whether there actually is an executable named g+ +, it is just assumed. this kind of leads autoconf ad absurdum, as we can simply check for a valid c++ compiler if needed. -- most important however: compiling Pd with a c++ compiler can be a bad idea! the Pd source uses C++ keywords (e.g. template is often used). throwing this code onto a c++ compiler leads to errors. conclusion: don't force autoconf to use g++ as the c-compiler, but rather let it choose the right compiler automagically if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner. Try building with the ASIO sources, which are C++ and need to be built with g++. gcc won't link C++ code into a C binary from what I could tell. So at least the final linking needs to be done with g++. In makefile.mingw, all C is built with gcc and all C++ is built with g++, then the whole thing is linked with g++. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] using the MSYS and Cygwin shells on the PdLab server
I'm cc'ing pd-dev so others may benefit from this. There is nothing
magic about the files in Cygwin and MSYS, they are all on the same
file system. The problem is each system has its own root path:
* in Windows, its C:\
* in Cygwin, its /cygdrive/c
* in MSYS, its /c
For /tmp in Cygwin, its C:\cygwin\tmp. I think MSYS uses the Windows
$TEMP or $TMP location.
As for ssh/scp and UNIX utils, I would stick with the Cygwin ones,
they work much better. I only use MSYS for running the actual builds,
and Cygwin for everything else.
I'll check the home dir perms, Windows is a pain to deal with, so
sorry its messed up.
.hc
On Sep 15, 2010, at 4:10 AM, IOhannes m zmoelnig wrote:
however, it' a bit awkward to get data into the msys shell.
is there any drive/mountpoint where i can share data between cygwin
and
msys?
in cygwin, my ${HOME} is C:\cygwin\home\pddev
in MSYS, my ${HOME} is C:\msys\1.0\home\pddev
in msys, it seems like i cannot access the cygwin home all, as this is
not mounted (via msys:/etc/fstab)
in cygwin, i can cd into /c/msys/1.0/home/pddev/, but i have no
permissions to write here.
in msys, if i open the shell using run...-C:\msys\1.0\msys.bat (or
Programs-MinGW-MSYS-MSYS), i get into /home/pddev (which seems to
be
C:\msys\1.0\home\pddev as well) but i have no permissions to write
either(!)
it seems like the only place i can write to from msys, is /tmp (which
according to msys:/etc/fstab is mapped from c:/DOCUME~1/pd/LOCALS~1/
Temp)
unfortunately i cannot access this path from neither cygwin nor from
plain windows (explorer, cmd), as i don't even have read
permissions.
so i thought about using a FAT32 partition (D:), as this is the usual
way to share data on w32 systems.
unfortunately i can only access it from cygwin and win, but not from
msys.
so i'm currently runing out of wit.
or do i have to scp things from cygwin to my local machine, then put
that onto an http server and download it within msys ;-)?
...i just noticed that there is an ssh client in msys as well, so i
could use that...
still doesn't sound very elegant to me...
i guess, if only one 3rd person (apart from you and me) has ever
logged
into the machine as pddev they had the same problems solved in some
way,
but it seems i cannot do it.
please help!
fgmasdr
IOhannes
Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you. - Richard M. Stallman
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] using the MSYS and Cygwin shells on the PdLab server
On 2010-09-15 15:25, Hans-Christoph Steiner wrote: I'm cc'ing pd-dev so others may benefit from this. There is nothing magic about the files in Cygwin and MSYS, they are all on the same file system. The problem is each system has its own root path: sure. * in MSYS, its /c ha, i didn't know that. c doesn't show up when doing ls / I'll check the home dir perms, Windows is a pain to deal with, so sorry its messed up. super. mfgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autotools on MinGW/MSYS
On 2010-09-15 15:20, Hans-Christoph Steiner wrote: if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner. Try building with the ASIO sources, which are C++ and need to be built i have to admit that i am unable to get that properly setup on the PdLab machine (no time for such things). if i could get a copy of everything needed for building (really no time for installing things on an os which i don't like; it's ok for just fixing bugs :-) i know somebody has to do that work and i hate to delegate it to e.g. you, but i think this is really a matter of efficiency), i will try. with g++. gcc won't link C++ code into a C binary from what I could tell. So at least the final linking needs to be done with g++. In that's what i was saying above: if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler) makefile.mingw, all C is built with gcc and all C++ is built with g++, then the whole thing is linked with g++. that's how it is supposed to be. afaik, automake provides easy ways for that... fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-3066945 ] Display position for Contextual menu bug
Bugs item #3066945, was opened at 2010-09-15 15:33 Message generated for change (Tracker Item Submitted) made by boonier You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3066945group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: boonier (boonier) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Display position for Contextual menu bug Initial Comment: Sometimes it appears randomly offset from the mouse cursor (to the left). Sometimes it appears right under the cursor (as expected). Generally I find creating a new canvas makes the menu appear normally. Does this have to do with the fact that some patches created in older versions have a 'dirty' flag or something that recreates the bug? (as it appears to work fine for newly created canvases) cheers Pd 0.42.5 extended rc6 Mac OS X 10.6.4 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3066945group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autotools on MinGW/MSYS
On 2010-09-15 15:56, IOhannes m zmoelnig wrote: On 2010-09-15 15:20, Hans-Christoph Steiner wrote: if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner. Try building with the ASIO sources, which are C++ and need to be built the current state of affairs can be found in my puredata repository at github (branch:3065532) http://github.com/umlaeute/pd-vanilla/tree/3065532 Pd mostly compiles on msys/mingw now (with the noteable exception of pd~, which has to be excluded on w32) automake now also produces a pd.def file for the exports (though there is still no pd.dll, since this is statically compiled into pd.exe) fgmasdf IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot on Macs and from git
2010/9/15 Hans-Christoph Steiner h...@at.or.at On Sep 14, 2010, at 5:08 PM, András Murányi wrote: At the moment buildbot fails with exceptions.RuntimeError: Couldn't find executable for 'svn' + the same for git I added ~buildbot/.bashrc to hopefully add Fink stuff to buildbot's environment .hc Hmm, didn't work out, and net.sourceforge.buildbot.plist has sw/bin in the path too, and svn is there, so i really don't know... Andras Ok, I was getting some builds from macosx104-i386, but then it disappeared, donno what happened there. macosx104-powerpc seems to be running still tho. Yea the process died somehow. I have restarted it with the command: /sw/bin/buildbot restart /Users/buildbot/macosx104-i386 The output had some complaints: /sw/lib/python2.6/site-packages/twisted/persisted/sob.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys /sw/lib/python2.6/site-packages/twisted/python/filepath.py:12: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha /sw/lib/python2.6/site-packages/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following twistd.log until startup finished.. /sw/lib/python2.6/site-packages/buildbot/scripts/logwatcher.py:52: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. env=os.environ, Removing stale pidfile /Users/buildbot/macosx104-i386/twistd.pid I worked on the pd-master/master.cfg a bit, including changing some of the names to be more consistent. I also got pure-data building from Miller's git. http://128.238.56.50:8010/builders/pure-data%20Linux%20debian-stable-i386/builds/6 .hc Good! I saw you stared experimenting with a builder for the externals too - do i understand right that at the end we will have every external built separately? I was thinking about breaking them out to a separate master, but then we'd need to duplicate every slave setup, so finally i think they could stay in the main master, and we could have each of their have their own category name, which allows for some selection at the web page. Also note that for the builders, you can define an array with slavenames: instead of a single string slavename, so you can test the same builder on multiple slaves at the same time. At the end they have to broken down to one slave per builder, otherwise the diag output is not easy to understand. Changing descriptionDone values to past tense like compiled may not make sense when the step fails and the output goes like compiled failed. Also there are things like autogen which don't have a proper past tense... :) Another thing i noticed an svn update by itself, i think we shall have the sources explicitly in master.cfg otherwise it will fail where the slave got reset. Also you told before we wanted clobber (tabula rasa) checkout not an update... I saw the make install, make uninstall steps in the output - having these would make much sense, fyi tests can be called with Test() which has some advantages over ShellCommand() like it doesn't make the whole build halt on failure. BTW switching the sources to git is easy, what we have to work out is Git polling. It's built into 0.8.1 but needs to triggered from git for 0.7.12. And then we have this thing with the poller to explain it which builder to start upon updates... a.k.a. the cake :) Andras ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autotools on MinGW/MSYS
On Wed, 2010-09-15 at 20:56 +0200, IOhannes m zmoelnig wrote: On 2010-09-15 15:56, IOhannes m zmoelnig wrote: On 2010-09-15 15:20, Hans-Christoph Steiner wrote: if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner. Try building with the ASIO sources, which are C++ and need to be built the current state of affairs can be found in my puredata repository at github (branch:3065532) http://github.com/umlaeute/pd-vanilla/tree/3065532 Pd mostly compiles on msys/mingw now (with the noteable exception of pd~, which has to be excluded on w32) automake now also produces a pd.def file for the exports (though there is still no pd.dll, since this is statically compiled into pd.exe) Sounds good! Thanks for sharing the pain of Windows! It'll be great once we can ditch the makefile.mingw once and for all. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot on Macs and from git
On Wed, 2010-09-15 at 22:11 +0200, András Murányi wrote: 2010/9/15 Hans-Christoph Steiner h...@at.or.at On Sep 14, 2010, at 5:08 PM, András Murányi wrote: At the moment buildbot fails with exceptions.RuntimeError: Couldn't find executable for 'svn' + the same for git I added ~buildbot/.bashrc to hopefully add Fink stuff to buildbot's environment .hc Hmm, didn't work out, and net.sourceforge.buildbot.plist has sw/bin in the path too, and svn is there, so i really don't know... Andras Ok, I was getting some builds from macosx104-i386, but then it disappeared, donno what happened there. macosx104-powerpc seems to be running still tho. Yea the process died somehow. I have restarted it with the command: /sw/bin/buildbot restart /Users/buildbot/macosx104-i386 The output had some complaints: /sw/lib/python2.6/site-packages/twisted/persisted/sob.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys /sw/lib/python2.6/site-packages/twisted/python/filepath.py:12: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha /sw/lib/python2.6/site-packages/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following twistd.log until startup finished.. /sw/lib/python2.6/site-packages/buildbot/scripts/logwatcher.py:52: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. env=os.environ, Removing stale pidfile /Users/buildbot/macosx104-i386/twistd.pid I worked on the pd-master/master.cfg a bit, including changing some of the names to be more consistent. I also got pure-data building from Miller's git. http://128.238.56.50:8010/builders/pure-data%20Linux% 20debian-stable-i386/builds/6 .hc Good! I saw you stared experimenting with a builder for the externals too - do i understand right that at the end we will have every external built separately? I was thinking about breaking them out to a separate master, but then we'd need to duplicate every slave setup, so finally i think they could stay in the main master, and we could have each of their have their own category name, which allows for some selection at the web page. Also note that for the builders, you can define an array with slavenames: instead of a single string slavename, so you can test the same builder on multiple slaves at the same time. At the end they have to broken down to one slave per builder, otherwise the diag output is not easy to understand. Changing descriptionDone values to past tense like compiled may not make sense when the step fails and the output goes like compiled failed. Also there are things like autogen which don't have a proper past tense... :) Another thing i noticed an svn update by itself, i think we shall have the sources explicitly in master.cfg otherwise it will fail where the slave got reset. Also you told before we wanted clobber (tabula rasa) checkout not an update... I saw the make install, make uninstall steps in the output - having these would make much sense, fyi tests can be called with Test() which has some advantages over ShellCommand() like it doesn't make the whole build halt on failure. BTW switching the sources to git is easy, what we have to work out is Git polling. It's built into 0.8.1 but needs to triggered from git for 0.7.12. And then we have this thing with the poller to explain it which builder to start upon updates... a.k.a. the cake :) Andras One approach would be to use multiple PBChangeSource things and have commit hooks report to buildbot that they should build: http://stackoverflow.com/questions/2795386/support-for-multiple-repositories-using-buildbot Another promising thing is loki, a web interface for easily setting up master/slaves: https://fedorahosted.org/loki/ .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot on Macs and from git
At the moment buildbot fails with exceptions.RuntimeError: Couldn't find executable for 'svn' + the same for git I added ~buildbot/.bashrc to hopefully add Fink stuff to buildbot's environment .hc Hmm, didn't work out, and net.sourceforge.buildbot.plist has sw/bin in the path too, and svn is there, so i really don't know... Andras Ok, I was getting some builds from macosx104-i386, but then it disappeared, donno what happened there. macosx104-powerpc seems to be running still tho. Yea the process died somehow. I have restarted it with the command: /sw/bin/buildbot restart /Users/buildbot/macosx104-i386 The output had some complaints: /sw/lib/python2.6/site-packages/twisted/persisted/sob.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys /sw/lib/python2.6/site-packages/twisted/python/filepath.py:12: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha /sw/lib/python2.6/site-packages/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following twistd.log until startup finished.. /sw/lib/python2.6/site-packages/buildbot/scripts/logwatcher.py:52: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. env=os.environ, Removing stale pidfile /Users/buildbot/macosx104-i386/twistd.pid I worked on the pd-master/master.cfg a bit, including changing some of the names to be more consistent. I also got pure-data building from Miller's git. http://128.238.56.50:8010/builders/pure-data%20Linux% 20debian-stable-i386/builds/6 .hc Good! I saw you stared experimenting with a builder for the externals too - do i understand right that at the end we will have every external built separately? I was thinking about breaking them out to a separate master, but then we'd need to duplicate every slave setup, so finally i think they could stay in the main master, and we could have each of their have their own category name, which allows for some selection at the web page. Also note that for the builders, you can define an array with slavenames: instead of a single string slavename, so you can test the same builder on multiple slaves at the same time. At the end they have to broken down to one slave per builder, otherwise the diag output is not easy to understand. Changing descriptionDone values to past tense like compiled may not make sense when the step fails and the output goes like compiled failed. Also there are things like autogen which don't have a proper past tense... :) Another thing i noticed an svn update by itself, i think we shall have the sources explicitly in master.cfg otherwise it will fail where the slave got reset. Also you told before we wanted clobber (tabula rasa) checkout not an update... I saw the make install, make uninstall steps in the output - having these would make much sense, fyi tests can be called with Test() which has some advantages over ShellCommand() like it doesn't make the whole build halt on failure. BTW switching the sources to git is easy, what we have to work out is Git polling. It's built into 0.8.1 but needs to triggered from git for 0.7.12. And then we have this thing with the poller to explain it which builder to start upon updates... a.k.a. the cake :) Andras One approach would be to use multiple PBChangeSource things and have commit hooks report to buildbot that they should build: Actually there is only one PBChangeSource needed/possible because it's a listener, and multiple commit hooks can communicate with it from the repos. Another promising thing is loki, a web interface for easily setting up master/slaves: https://fedorahosted.org/loki/ Hm. Seems a bit young to me... I see that at the moment every factory is under construcion so i won't touch the config file for a while so that you can edit around. (Which makes me think about putting it in svn later...) http://128.238.56.50:8010/one_box_per_builder Andras ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] 0.43 failing on make uninstall
I'm enjoying this new buildbot, its really quite nice. We now have the pure-data.git builds set up to do the build in multiple steps (git, ./autogen.sh, configure, compile, make dist, make install, make uninstall): http://128.238.56.50:8010/builders/pure-data%20Linux% 20debian-stable-i386/builds/7 One thing is caught is that it is failing on make uninstall: http://128.238.56.50:8010/builders/pure-data%20Linux% 20debian-stable-i386/builds/7/steps/make%20uninstall/logs/stdio ...usr/local/lib/pd/extra/expr~: No such file or directory .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot on Macs and from git
On Thu, 2010-09-16 at 02:31 +0200, András Murányi wrote: At the moment buildbot fails with exceptions.RuntimeError: Couldn't find executable for 'svn' + the same for git I added ~buildbot/.bashrc to hopefully add Fink stuff to buildbot's environment .hc Hmm, didn't work out, and net.sourceforge.buildbot.plist has sw/bin in the path too, and svn is there, so i really don't know... Andras Ok, I was getting some builds from macosx104-i386, but then it disappeared, donno what happened there. macosx104-powerpc seems to be running still tho. Yea the process died somehow. I have restarted it with the command: /sw/bin/buildbot restart /Users/buildbot/macosx104-i386 The output had some complaints: /sw/lib/python2.6/site-packages/twisted/persisted/sob.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys /sw/lib/python2.6/site-packages/twisted/python/filepath.py:12: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha /sw/lib/python2.6/site-packages/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following twistd.log until startup finished.. /sw/lib/python2.6/site-packages/buildbot/scripts/logwatcher.py:52: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. env=os.environ, Removing stale pidfile /Users/buildbot/macosx104-i386/twistd.pid I worked on the pd-master/master.cfg a bit, including changing some of the names to be more consistent. I also got pure-data building from Miller's git. http://128.238.56.50:8010/builders/pure-data%20Linux % 20debian-stable-i386/builds/6 .hc Good! I saw you stared experimenting with a builder for the externals too - do i understand right that at the end we will have every external built separately? I was thinking about breaking them out to a separate master, but then we'd need to duplicate every slave setup, so finally i think they could stay in the main master, and we could have each of their have their own category name, which allows for some selection at the web page. Also note that for the builders, you can define an array with slavenames: instead of a single string slavename, so you can test the same builder on multiple slaves at the same time. At the end they have to broken down to one slave per builder, otherwise the diag output is not easy to understand. Changing descriptionDone values to past tense like compiled may not make sense when the step fails and the output goes like compiled failed. Also there are things like autogen which don't have a proper past tense... :) Another thing i noticed an svn update by itself, i think we shall have the sources explicitly in master.cfg otherwise it will fail where the slave got reset. Also you told before we wanted clobber (tabula rasa) checkout not an update... I saw the make install, make uninstall steps in the output - having these would make much sense, fyi tests can be called with Test() which has some advantages over ShellCommand() like it doesn't make the whole build halt on failure. BTW switching the sources to git is easy, what we have to work out is Git polling. It's built into 0.8.1 but needs to triggered from git for 0.7.12. And then we have this thing with the poller to explain it
