[CMake] Properly Detecting Win64

David Cole david.cole at kitware.com
Wed Apr 20 12:23:41 EDT 2011 

On Wed, Apr 20, 2011 at 12:05 PM, j s <j.s4403 at gmail.com> wrote:

> On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson
> <mike.jackson at bluequartz.net> wrote:
> > I normally do this also BUT sometimes I try to short circuit the process
> because I just want to regenerate the Solution/Projects and not have to wait
> for a complete CMake configuration which takes a really long time on some
> project due to the number of tests that need to be performed. At the time
> this seems like a reasonable approach, just blow away everything except the
> cache and let cmake regenerate everything else. Now I know this really isn't
> a good idea. So maybe a bug maybe an "operator" error.
>
> I've always had very bad luck with the Visual Studio projects
> generator, and always start from a clean directory when something in
> the configuration changes.  I only run the default configuration tests
> and I set the paths manually for all of my dependencies, so that saves
> some time.
>
> If I am just adding a source file, I can usually get away with not
> blowing everything away.  However, I do close Visual Studio first,
> because of issues with the cmake scripts being run by the visual
> studio project.  The cmake gui is typically sufficient for updating
> the build directory.
>
> Regards,
>
> Juan
>
>
> > ___________________________________________________________
> > Mike Jackson                      www.bluequartz.net
> > Principal Software Engineer       mike.jackson at bluequartz.net
> > BlueQuartz Software               Dayton, Ohio
> >
> > On Apr 20, 2011, at 11:52 AM, j s wrote:
> >
> >> If it helps, I always configure from a clean directory.  This script
> >> is written in bash for cygwin, but I'm sure it would be easy enough to
> >> do from some other script:
> >>
> >> CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe
> >> mkdir win32
> >> (cd win32; "$CMAKE" -G "Visual Studio 10" ..)
> >> mkdir win64
> >> (cd win64; "$CMAKE" -G "Visual Studio 10 Win64" ..)
> >>
> >> where ".." is my top level directory containing a CMakelists.txt.  I
> >> have no problems then with:
> >> IF (WIN32)
> >> IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
> >> ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
> >> ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
> >> ENDIF (WIN32)
> >>
> >> in my files.
> >>
> >> Juan
> >>
> >> On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson
> >> <mike.jackson at bluequartz.net> wrote:
> >>>
> >>> On Apr 20, 2011, at 8:55 AM, David Cole wrote:
> >>>
> >>>>
> >>>>
> >>>> On Tue, Apr 19, 2011 at 5:44 PM, James Bigler <jamesbigler at gmail.com>
> wrote:
> >>>> On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman <
> bill.hoffman at kitware.com> wrote:
> >>>> On 4/12/2011 4:13 PM, David Cole wrote:
> >>>>
> >>>> Does somebody have reproducible steps to get to the point where
> >>>> CMAKE_SIZEOF_VOID_P disappears??
> >>>>
> >>>> I've never seen that...
> >>>>
> >>>> How many times do you have to re-configure before you start seeing
> this
> >>>> behavior? That sounds like something is just really wrong somewhere,
> and
> >>>> it would be a good thing to track down exactly what that is.
> >>>>
> >>>> This variable is stored in this file:
> >>>>
> >>>> CMakeFiles/CMakeCCompiler.cmake
> >>>>
> >>>> It should not go away.
> >>>>
> >>>> -Bill
> >>>>
> >>>>
> >>>>
> >>>> I just had this happen to one of my colleagues with a fresh build
> directory.  When I looked into CMakeCCompiler.cmake this is what I found:
> >>>>
> >>>> # Save compiler ABI information.
> >>>> SET(CMAKE_C_SIZEOF_DATA_PTR "")
> >>>> SET(CMAKE_C_COMPILER_ABI "")
> >>>>
> >>>> IF(CMAKE_C_SIZEOF_DATA_PTR)
> >>>>   SET(CMAKE_SIZEOF_VOID_P "${CMAKE_C_SIZEOF_DATA_PTR}")
> >>>> ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
> >>>>
> >>>> For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
> >>>>
> >>>> What could cause this to happen?  Is there perhaps a race condition or
> some other failure when CMake detects this value?
> >>>>
> >>>> James
> >>>>
> >>>>
> >>>> If it is a race condition that simply occurs "sometimes, sproadically"
> then we should be able to reproduce this by writing a script that tries to
> configure a project over and over again into a clean directory.
> >>>>
> >>>> But I'm not convinced it's as simple as that. There must be something
> happening (or some condition on certain machines/platforms/compilers) that
> triggers it... otherwise, we'd see this on the CMake dashboard results
> sometimes, wouldn't we?
> >>>>
> >>>> What compiler/generator are you using in this instance?
> >>>> Does it repeat with a fresh build directory on this project in this
> environment? Or does it go away with a new fresh build?
> >>>>
> >>>> Is the project that demonstrates this behavior public? (Can I try it
> here...?)
> >>>>
> >>>> Thanks,
> >>>> David
> >>>>
> >>>  I have a small project (http://scm.bluequartz.net/eim/emmpm) that I
> can reproduce on. If you do a checkout you will need to do a git clone
> --recursive due to the use of git submodules. It also depends on libTiff.
> This is what I do to reproduce the issue.
> >>>
> >>> On Windows 7 x64 (Ultimate in my case) running from a MSVC Command
> Prompt x64 I invoke cmake-gui.exe and configure the project for Visual
> Studio 9 2008 x64. Configure and then generate. Close CMake-GUi.exe. Out in
> Windows explorer navigate to the build directory and delete EVERYTHING
> except CMakeCache.txt. I then run cmake.exe from the build directory from
> the same command prompt as I invoked cmake-gui.exe from. I now get the
> following error:
> >>>
> >>>
> >>> -- Generating Copy Rule for Debug DLL Library
> C:/Developer/x64/tiff/bin/tif
> >>> -- Generating Copy Rule for Release DLL Library
> C:/Developer/x64/tiff/bin/t
> >>> -- Generating Install Rule for DLL Library
> C:/Developer/x64/tiff/bin/tiffdl
> >>> -- Generating Install Rule for DLL Library
> C:/Developer/x64/tiff/bin/tiffdl
> >>> -- CMAKE_SIZEOF_VOID_P:
> >>> CMake Warning at Resources/CPack/PackageProject.cmake:53 (if):
> >>>  given arguments:
> >>>
> >>>    "EQUAL" "8"
> >>>
> >>>  Unknown arguments specified
> >>> Call Stack (most recent call first):
> >>>  CMakeLists.txt:149 (include)
> >>>
> >>>
> >>> -- Configuring done
> >>> -- Generating done
> >>> -- Build files have been written to:
> C:/Users/mjackson/Workspace/emmpm/x64
> >>>
> >>> And here is the cmake code that causes the issues:
> >>>
> >>> if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8)
> >>>    set(CPACK_PACKAGE_FILE_NAME
> "${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win64")
> >>> else()
> >>>    set(CPACK_PACKAGE_FILE_NAME
> "${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win32")
> >>> endif()
> >>>
> >>> Hope that helps
> >>> ___________________________________________________________
> >>> Mike Jackson                      www.bluequartz.net
> >>> Principal Software Engineer       mike.jackson at bluequartz.net
> >>> BlueQuartz Software               Dayton, Ohio
> >>> _______________________________________________
> >>> 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
>


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110420/8fe515cd/attachment-0001.htm>

More information about the CMake mailing list