Re: [CMake] Properly Detecting Win64 - [Semi Off Topic Reply]
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
Re: [CMake] Properly Detecting Win64 - [Semi Off Topic Reply]
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? 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
Re: [CMake] Properly Detecting Win64 - [Semi Off Topic Reply]
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
Re: [CMake] Properly Detecting Win64 - [Semi Off Topic Reply]
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
