|
|
Boost Interest : |
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-06-06 20:16:55
David Abrahams wrote:
>>
>> inside macro boost_test_compile(). This needs to be checked that the
>> compile command generated actually makes sense on windows.
>
> Nit: it's not a question of Windows-or-not-Windows, but that we need to
> check that it makes sense on all compilers. I run the cygwin compiler
> on windows (i.e. not from inside the cygwin bash shell) and it uses the
> ".o" extension for object files, but the usual extension on Windows is
> ".OBJ". I'm not sure which extension is habitually used for mingw
> compilations.
.o vs .OBJ was easy enough to fix, committed something for that. Anyhow
each platform will have to be played with. I don't see any showstoppers
coming though.
>
>> boost_test_link is still broken.
>>
>> The *_fail tests require one to use a wrapper script to flip the exit
>> status of test subprocesses. They need checking on windows, see
>> below.
>
> Troy, if you want access to a virtual Windows machine for testing some
> of this stuff, just give me the word.
I'd sorta prefer to stay ignorant, though if nobody else digs in I may
end up taking you up on this, or imposing on some of my local windows-savvy
colleagues.
>> --- BOOST_BUILD_SLAVE ---
>>
>> I added a cmake option BOOST_BUILD_SLAVE which turns on generation of
>> xml from all build steps, and turns on per-library calls to a script
>> which (eventually) will HTTP POST build results; currently the POST
>> script just cats the xml logs to stdout and clears them. These POST
>> calls happen after the build and after the test of each library. To
>> me the post rate looks about right, of course it varies depending on
>> the size of the library.
>
> Personally I'd like to post as each object file was compiled... although
> (granting that I don't really know what I'm talking about) I wonder if
> we don't want XML-RPC rather than POST. Doesn't the former allow us to
> keep a connection open while the latter has to make a new one for each
> POST?
The former doesn't, as the driver script is called anew for each compilation step.
The cmake code as it is now does intermittent batches of xmlrpc calls. Maybe
you could hold the connection open with a local proxy, but I think you're not getting
much bang for your complexity buck doing this.
>> The magic is in BoostBuildSlave.cmake, wherein you will see things
>> like:
>>
>> set(CMAKE_CXX_COMPILE_OBJECT
>> "${BOOST_TEST_DRIVER} <CMAKE_CURRENT_BINARY_DIR> cxx_compile_object <OBJECT> ${CMAKE_CXX_COMPILE_OBJECT}")
>>
>> Where BOOST_TEST_DRIVER is one of the python driver scripts in
>> tools/build/CMake. These are configured by cmake at makefile
>> generation time.
>
> You mean they're generated? if not, what does it mean to "configure a
> python driver script?"
>
Yeah, configure == generated; just a copy into the build area plus expansion
of cmake variables. Have a look at tools/build/CMake/*.py.in
> The one thing I worry about with something like that is getting shell
> quoting right. Does the extra step of going through xmlize.py strip a
> level of quotes? Or does cmake not actually issue its commands to the
> shell (say yes, please!)?
Dunno offhand. We should just try it and see what happens. I think cmake is pretty
smart here.
[snip]
>troy wrote:
>> TODO
>>
>> - On windows, make sure this is all going to work. Get those python
>> scripts working and happy over there.
haven't touched this one
>> - Think more carefully about the structure of the XML. It isn't quite
>> complete at the moment, some information e.g. about parents of
>> current tasks is left out (it is available to the POST script, just
>> not part of the XML).
there is no more xml :). there will probably be a tweak or two to come
w.r.t. the structure of the data, but nothing major.
>> - Put together targets for reporting the number of steps in an upcoming
>> build, svn url/rev of the codebase, etc.
got the svn url/rev in there (see target slave-start)...
the "here's what I'm gonna do" part, to allow 'M of N steps completed' display,
is an open issue.
>>
>> - Consider the business of triggering these builds. Probably another
>> little python script using the svn bindings.
or one that makes an xmlrpc call to the trac plugin...
>> - Revamp 'traash' to ingest/display these build results.
first cut at this is done, see my recent post titled 'traash' demo
>
> Niftypifty! Pretty soon we'll have to start talking about what kind of
> display we really want.
>
I think we can start talking about this now... As I mentioned, I've seen
some of Evan's consulting work (some very elaborate web front-ends)
and it is absolutely killer, I'm looking forward to seeing what he comes
up with. I'll get the source to the plugin up asap.
-t