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. 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