On Wed, Apr 20, 2011 at 12:58 PM, j s <j.s4...@gmail.com> wrote: > On Wed, Apr 20, 2011 at 12:04 PM, David Cole <david.c...@kitware.com> wrote: >> But you've blown everything else away at that point, so the *build* is a >> full rebuild, right? >> >> CMake configure takes 60 seconds, but how long does the full build take? > > My guess is that CMake is invoking a lot of processes in running its > tests. Creating a process on windows is very expensive. I suspect > having an equivalent solution written with make in cygwin would be > very slow as well.
I do remember now that cygwin on Windows 7 64 bit is a lot slower than Windows 7 32 bit. Perhaps you can try running some comparisons with 32 bit Windows. This is possible because I believe that Visual Studio is a 32 bit program. Juan > > Juan > >> >> >> On Wed, Apr 20, 2011 at 12:58 PM, Michael Jackson >> <mike.jack...@bluequartz.net> wrote: >>> >>> Hey Dave, >>> So here are some timings for running CMake to the point where I can >>> actually build my project. THe hardware is an Mac Pro 8 Core (16 Thread) >>> 2.6GHz OS X 10.6.6 box also running Windows 7 x64. On OS X I use Makefiles >>> in combination with Eclipse as the IDE so I generate straight Makefiles. On >>> this system my project takes 10 seconds to configure to a point where it is >>> ready to compile. On Windows using Visual Studio 9 2008 x64 as the generator >>> this takes 58 seconds. When you are heavy into development where the CMake >>> files are changing a bunch and there are lots and lots of runs of CMake then >>> yes I thought I was taking a shortcut. Unfortunately this shortcut proved to >>> have very bad side effects and now I don't do it any more. But still, 10 >>> seconds versus 60 Seconds can be a frustrating difference when deadlines are >>> looming and you are needing to go faster. >>> >>> -- >>> Mike Jackson <www.bluequartz.net> >>> >>> On Apr 20, 2011, at 12:23 PM, David Cole wrote: >>> >>> > >>> > In my opinion, blowing away everything except for the CMakeCache.txt >>> > file is asking for trouble, and puts you in an invalid (or at the very >>> > least, unexpected) state. Because some of the cached values may depend on >>> > some of the stuff that was just blown away. If you're blowing everything >>> > else away, why not blow away CMakeCache.txt, too? Is the CMake configure >>> > that high a percentage of your total build time that saving a few minutes >>> > on >>> > the whole makes it worth trouble like this? >>> > >>> > However, even so, I would like to understand and track down the source >>> > and the root cause of this trouble with CMAKE_SIZEOF_VOID_P -- because its >>> > correctness is arguably very important for many projects out there. >>> > >>> > So -- if somebody has a way to reproduce this without blowing away >>> > everything except for the CMakeCache.txt, I'd still like to hear it. >>> > >>> > >>> > Thanks, >>> > David >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Follow this link to subscribe/unsubscribe: >>> http://www.cmake.org/mailman/listinfo/cmake >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake >> > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake