[CMake] Properly Detecting Win64 - [Semi Off Topic Reply]

[j s]

On Wed, Apr 20, 2011 at 12:58 PM, j s <j.s4403 at gmail.com> wrote:
> On Wed, Apr 20, 2011 at 12:04 PM, David Cole <david.cole at 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.jackson at 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
>>
>