|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-06-08 18:52:10
on Fri Jun 06 2008, "troy d. straszheim" <troy-rPoGFrA5WPqukZHgTAicrQ-AT-public.gmane.org> wrote:
> 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.
Nice.
> 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.
For what it's worth, it's been my experience that when the lead guy
tries to stay ignorant of one of the platforms, the software's
cross-platform-ness is usually severely compromised.
>>> --- 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.
Well, you could launch a daemon or something, but your point is taken.
> 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.
We'll have to try it. No sense in optimizing prematurely.
>>> 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
Will do.
>> 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.
Okey. We'll have to throw some bad cases (e.g. spaces in pathnames,
which we don't have today) in to see if it really works.
> [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
I'll try to get my XP32 and XP64 VMs testing this stuff.
>>> - 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.
Awesome.
>>> - 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.
Okay.
>>> - 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...
That's what Bitten does. The slaves poll the trac plugin periodically
to see if there's anything to do. The server knows what changed in the
repo, what area of the repo the recipe is testing, and what platforms
have tested what revisions. We'd probably want to do it a little
differently, but one thing that we should keep is that Bitten always
starts testing with the latest revision and works its way back through
untested revs.
>>> - Revamp 'traash' to ingest/display these build results.
>
> first cut at this is done, see my recent post titled 'traash' demo
I like it.
>> 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,
Evan? I'm trying to remember... is that the guy you were hanging with
at BoostCon?
> I'm looking forward to seeing what he comes up with. I'll get the
> source to the plugin up asap.
I'll try to set up some slaves in the next couple days. Thanks for all
your work on this!
-- Dave Abrahams BoostPro Computing http://www.boostpro.com