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
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
