on Sat Feb 07 2009, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
> David Abrahams wrote: >> on Thu Feb 05 2009, Michael Jackson <mike.jackson-AT-bluequartz.net> wrote: >> >>> 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 >> >> If that's the only path to parallel builds with CMake on windows, it >> seems like a very significant weakness. >> > There are two paths right now: > > 1. the cygwin gmake (has to be CVS gmake ). The issue is the jobserver code > in gmake > is only available in a posix environment right now. The gmake that ships > with cygwin > right now can not handle paths with c: in them, but only the /cygdrive/c > style of > path, and the ms compiler of course does not know about /cygdrive/c. I think you might be able to get around that by inserting hardlinks at the root of the drive. Ugly, though. > The fix for this is in CVS gmake. There are some KDE folks working on > a windows solution for the jobserver gmake code that can be merged > into gmake. Once that happens there will be a third option. > > 2. or you can use the visual studio project files with vsbuild or the devenv > tool > itself. > > I use 1 most of the time for myself, and it is not so hard, but you do have > to install > the base cygwin package. Doesn't bother me either, but it will bother some. > Many developers at Kitware use 2. I really don't see this as > a huge issue. There are in fact two working paths for parallel builds on > Windows. > However, I do think that the visual studio project style of build needs to be > tested, > and will be most commonly used by Windows developers. So, relying on > makefile only > cmake for testing on Windows will not be a good idea. But the real problem here is that anyone wanting to contribute a testing server will have a tough time making good use of his hardware, because --- unless I'm mistaken --- you can't automate the VS-based builds. ...or am I missing something? -- 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
