Re: [Boost-cmake] Analysis of the current CMake system
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
Re: [Boost-cmake] Parallel Builds on Windows (Was: Analysis of the current CMake system)
There are those in the CMake community that successfully combine "unix makefiles" with the Visual Studio Compilers to perform parallel builds. http://www.cmake.org/pipermail/cmake/2008-June/022178.html is one of the relevant threads. Here is another thread that has some important information about exactly what versions of gmake and others to use. http://www.cmake.org/pipermail/cmake/2008-April/021336.html Hope some of that helps _ Mike Jackson mike.jack...@bluequartz.net BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio On Feb 5, 2009, at 6:08 AM, Ingo Albrecht wrote: 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. ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Parallel Builds on Windows (Was: Analysis of the current CMake system)
Michael Jackson schrieb: There are those in the CMake community that successfully combine "unix makefiles" with the Visual Studio Compilers to perform parallel builds. http://www.cmake.org/pipermail/cmake/2008-June/022178.html is one of the relevant threads. Here is another thread that has some important information about exactly what versions of gmake and others to use. http://www.cmake.org/pipermail/cmake/2008-April/021336.html Yes, I've seen this. Sadly it requires MSYS, which might just be good enough for me if its packaging structure wouldn't require people to gather required packages by hand from a download repository, most packages there also being somewhat outdated. Using a hand-picked and custom-patched make.exe seems even more disturbing. The VS generator, on the other hand, gives a nice and polished work environment, which from my outside perspective is much more appropriate for boost. Hope some of that helps On Feb 5, 2009, at 6:08 AM, Ingo Albrecht wrote: 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. ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] Using QuickBook without Boost.Build
Hi, The QuickBook toolchain is a bit tricky to set up properly. According to https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted the chain to generate .html from a .qbk file is QuickBook -> BoostBook -> DocBook -> HTML According to the documentation of QuickBook http://www.boost.org/doc/libs/1_37_0/doc/html/quickbook.html QuickBook will need Boost.Build, hence bjam. However, this documentation might be obsolete. I was wondering whether this "cmake project" found a way to process QuickBook documentation without falling back to bjam based Boost.Build. (Just looking for a clear answer, I have no problems using Boost.Build for processing QuickBook.) Regards, Thomas -- "Der Pessimist behauptet, dass alles schon so schlimm ist, dass es gar nicht mehr schlimmer sein könnte. Worauf der Optimist erwidert: Oh doch!" - Vladimir Bukowsky Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Using QuickBook without Boost.Build
Thomas Klimpel wrote: Hi, The QuickBook toolchain is a bit tricky to set up properly. According to https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted the chain to generate .html from a .qbk file is QuickBook -> BoostBook -> DocBook -> HTML According to the documentation of QuickBook http://www.boost.org/doc/libs/1_37_0/doc/html/quickbook.html QuickBook will need Boost.Build, hence bjam. However, this documentation might be obsolete. I was wondering whether this "cmake project" found a way to process QuickBook documentation without falling back to bjam based Boost.Build. (Just looking for a clear answer, I have no problems using Boost.Build for processing QuickBook.) Boost-cmake can do it, there is nothing inherent to the task that excludes cmake or any other build tool. In fact I recently started quickbookizing the docs from the wiki, and boost-cmake can build them. That said, not all projects are set up on the cmake side (you have to specify where your docs are, etc., from your library's CMakeLists.txt) and I'm sure it needs some tweaking, as the toolchain is indeed brittle. If you want to play with it and try to tune it up a bit, be my guest :) -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Analysis of the current CMake system
Ingo Albrecht wrote: 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 Interesting, thanks for this. Would the 'cwrap' approach (where the compiler is called via a wrapper) work under vcbuild? (Forgive me, I don't do windows). The only reason I paid attention to NMAKE is that it was somewhat familiar to me. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Analysis of the current CMake system
troy d. straszheim wrote: 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 Interesting, thanks for this. Would the 'cwrap' approach (where the compiler is called via a wrapper) work under vcbuild? (Forgive me, I don't do windows). The only reason I paid attention to NMAKE is that it was somewhat familiar to me. No, that would not help. vcbuild uses the project files. CTest can already run devenv from the command line which is almost the same thing. I think with VS you really have to test the project files for performance, and to make sure they work. We are working on a way of extracting the build information from the log files produced by VS. -Bill ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
