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

Subject: Re: [Boost-cmake] Analysis of the current CMake system
From: David Abrahams (dave_at_[hidden])
Date: 2009-01-16 18:32:31

on Thu Jan 15 2009, Brad King <brad.king-AT-kitware.com> 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 know for a fact it's possible to hook the builtin VS IDE compiler
command.  After all, that happens when you install the Intel compiler
chain.  In fact, I think you get a menu that lets you choose which
toolset you're using under the covers.

>>> We could make this a CMake feature by teaching the generators to wrap
>>> the compiler up with a tool we distribute with CMake.  Then you won't
>>> have to hack the compilation rule variables for Boost or depend on
>>> python.
>> 
>> Presumably the name of this tool (let's call it CWrap?) would have some
>> interface that you could implement however you like... and if that is
>> implementable in python, you've given your users lots of ways to tweak
>> their build system.   We're OK with being dependent on python.
>
> Whatever interface we create to tell the generators to do this can also
> specify the wrapper (hook) command.  We can provide a simple tool to be
> used by default and just specify a command-line interface for a custom tool.

e.g. "python some_script.py ..."

>>> Testing with ctest's --build-and-test feature.  The entire build and
>>> execution of every test would be captured independently of other tests.
>> 
>> Or a python script that does what ctest's --build-and-test does...
>> IMV a lot more flexibility, a lot less code.
>
> How is duplicating functionality less code?  If --build-and-test is
> missing something, we can extend it.

Whatever you guys can provide quickly enough to keep us from wanting to
build it ourselves will be most gratefully appreciated!

>>> The code in question tells CMake to generate a python script that looks
>>> like this (on Windows):
>>>
>>>   sys.path.append("c:\path\with\backslashes\to\some\file.txt")
>>>   #                                        ^^ escape sequence?
>>>
>> 
>> I'd have to look back.  This stuff was indeed working on windows;
>> anyhow, looks like we can detangle a lot of this with some of your help
>> making tweaks to cmake itself.
>
> Python seems to leave the backslashes if the sequence doesn't happen to
> be a supported escape.  You may just be getting lucky.

Fortunately it's easy enough to keep luck out of the equation in this
case.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com