Boost Interest :
Subject: Re: [Boost-cmake] Parallel Builds on Windows
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-08 06:58:11
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"
>>> the Visual Studio Compilers to perform parallel builds.
>>> http://www.cmake.org/pipermail/cmake/2008-June/022178.html is one of the relevant
>>> Here is another thread that has some important information about exactly what
>>> of gmake and others to use.
>> 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
> 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