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