Re: [Boost-cmake] Analysis of the current CMake system

Subject: Re: [Boost-cmake] Analysis of the current CMake system
From: Ingo Albrecht (ingo.albrecht_at_[hidden])
Date: 2009-02-05 06:08:04

troy d. straszheim schrieb:
> Brad King wrote:
>> troy d. straszheim wrote:
>>> I don't quite get "That doesn't mean we can't test some tools without
>>> log-scraping".
>>>
>>> I see two different cases here.  There's the developer working under
>>> visual studio or emacs who wants to run some tests.  This guy knows (or
>>> should know) how to find what compile/link flags were used, chase down
>>> warnings and whatnot.  In this case the message "test X failed, go look
>>> at the logs" is fine.  Let the user use his tool.
>>
>> How do we know that a VS IDE build works unless we test it?  Testing it
>> requires log scraping unless we write some kind of plugin, which may not
>> be possible for all tools.  Even if we do log scraping for VS IDE
>> builds, we can still use "CWrap" for generators where it can be 
>> implemented.
>
> I think we're agreeing here.  There is testing the VS IDE build, and 
> then there is testing the VS IDE build and trying to report every 
> single thing that could go wrong in the course of the build to a 
> cdashish server somewhere.  I'd assume that IDE builds would need to 
> be tested by somebody sitting in front of the IDE.  If something goes 
> wrong the IDE tells you and you go figure out what it is. make and 
> nmake builds, running on slaves in a datacenter someplace, would need 
> to report everything that goes  wrong.  I don't think the 
> slave-testing-process should get complicated by IDEs that constantly 
> get tested manually anyhow.
Note that vcbuild (the command line driver for VS builds) has command
line arguments for specifying strings to prefix log messages at various log
levels with. This should make log scraping of the compilation much more
reliable, although it still disgusts me. This does not work for CTest though
because it tests using cmake scripts.

Running vcbuild is certainly no alternative for trying the build in the IDE,
but it should be sufficient for continuous integration.

Further, I have to note that command-line VS builds should be
supported for one simple reason: nmake does not support parallel
builds and probably never will. This makes VS the easiest way of
running a parallel build on Windows (locally or distributed with
additional tools). GNU make from MSYS is out of the question
because MSYS seems far from production-grade.

Should IDE builds be considered support-worthy, it would of
course be necessary to test manually before releases.

I hope that some of this helps
  Ingo

PS On my background:
I'm a Berlin-based software developer currently building
a new CMake-based build system for our pretty extensive
in-house media engine, to be found with source at
http://y60.artcom.de/. No boost in there though. Yet.