Re: [CMake] Properly Detecting Win64
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
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
___
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
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
___
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
On Apr 20, 2011, at 8:55 AM, David Cole wrote:
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@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.jack...@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
Re: [CMake] Properly Detecting Win64
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.jack...@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 jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@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.jack...@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:
Re: [CMake] Properly Detecting Win64
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.
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@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.jack...@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 jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@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)
Re: [CMake] Properly Detecting Win64
On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson
mike.jack...@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.jack...@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.jack...@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 jamesbig...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@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
Re: [CMake] Properly Detecting Win64
On Wed, Apr 20, 2011 at 12:05 PM, j s j.s4...@gmail.com wrote:
On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson
mike.jack...@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.jack...@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.jack...@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 jamesbig...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman
bill.hoff...@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
Re: [CMake] Properly Detecting Win64
On Wed, Apr 20, 2011 at 10:23 AM, David Cole david.c...@kitware.com wrote:
On Wed, Apr 20, 2011 at 12:05 PM, j s j.s4...@gmail.com wrote:
On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson
mike.jack...@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.jack...@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.jack...@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 jamesbig...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman
bill.hoff...@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
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
Re: [CMake] Properly Detecting Win64
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
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
___
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
Maybe you can base the package name by testing the generator name.
I need to do that to e.g. get a useful build naming in CTest scripts. At
that point CMAKE_SIZEOF_VOID_P is not available anyway. And I think that
using this is just a bad idea. How do you decide if it's IA64 or AMD64?
I use this at the moment:
FUNCTION(GET_NMAKE_VERSION_STRING var)
IF(MSVC_VERSION EQUAL 1400)
SET(ver_string vs8)
ELSEIF(MSVC_VERSION GREATER 1599)
SET(ver_string vs10)
ELSEIF(MSVC_VERSION GREATER 1499)
SET(ver_string vs9)
ELSEIF(CMAKE_COMPILER_2005)
SET(ver_string vs7)
ELSE(MSVC_VERSION EQUAL 1400)
SET(ver_string vs6)
ENDIF(MSVC_VERSION EQUAL 1400)
SET(${var} ${ver_string} PARENT_SCOPE)
ENDFUNCTION(GET_NMAKE_VERSION_STRING)
# CMAKE_SIZEOF_VOID_P doesn't work here because there
# was no compiler detection until now
IF (WIN32)
SET(CMAKE_CXX_COMPILER cl)
EXECUTE_PROCESS(COMMAND ${CMAKE_CXX_COMPILER}
OUTPUT_VARIABLE _DEV_NULL
ERROR_VARIABLE _COMPILER_OUTPUT)
STRING(REGEX REPLACE Version .* CTEST_COMPILER
${_COMPILER_OUTPUT})
IF (_COMPILER_OUTPUT MATCHES for x64)
SET(_BUILD_64_BIT TRUE)
ELSE ()
SET(_BUILD_64_BIT FALSE)
ENDIF ()
...
A case for IA64 can be easily added at this point. Those CTest scripts are
only used with NMake at the moment so there is no case for Visual Studio
generators. But that can also easily be added with IF (CMAKE_GENERATOR
MATCHES AMD64$) or something like that.
HTH
Eike
___
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
Maybe you can base the package name by testing the generator name. I need to do that to e.g. get a useful build naming in CTest scripts. At that point CMAKE_SIZEOF_VOID_P is not available anyway. And I think that using this is just a bad idea. How do you decide if it's IA64 or AMD64? [...] And if you are inside the build you have also CMAKE_CL_64. At least when using NMake. IIRC it is not set when using the Visual Studio Generators so you are back to the previously posted solution. Eike ___ 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
On Mon, Jan 17, 2011 at 11:27 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Jan 17, 2011, at 1:23 PM, Eric Noulard wrote:
2011/1/17 Michael Jackson mike.jack...@bluequartz.net:
I have the following code:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win64)
elseif( ${CMAKE_SIZEOF_VOID_P} EQUAL 4 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win32)
else()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Unknown)
endif()
I properly generate VS 2008 Win64 projects. Everything builds fine. When
I build the PACKAGE project I get a zip file with -Unknown in the name.
This will usually configure OK the first time or so, ie, I get a Zip file
name with -Win64 but after a few more configs this seems to revert back to
Unknown. Searching the CMakeCache.txt file for CMAKE_SIZEOF_VOID_P
comes up empty. Is this some sort of temporary variable?
Shouldn't be temporary just not in cache.
Do I need to store it in my own cache variable somewhere?
I don't think you should.
Looks like a bug to me, how come CMAKE_SIZEOF_VOID_P
would it be defined sometimes but not **always**...
need to dive into the source of this definition, may be it is not always
defined because it is indirectly defined in the chain of CMake
processing due
to CMake cache.
By the way shouldn't you use
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
instead of
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
from the doc I think EQUAL is for values whereas STREQUAL is for string.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
It seems like if I start with a clean build directory then
CMAKE_SIZEOF_VOID_P will be the proper value for the environment I am
running in. But then after a while (many runs of CMake) the value seems to
get lost or otherwise is NOT in the cache any longer. Kind of odd really.
You are probably right about the improper use of the if command. I never
really know which one to use and when something does not work when I _think_
it really *should* work then I start trying all sorts of stuff.
Maybe someone else has some ideas as to why CMAKE_SIZEOF_VOID_P might not
be defined.
___
Mike Jackson www.bluequartz.net
___
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
I've also seen this, and I would appreciate if anyone else who experiences
this could chime in, so that we might be able to start profiling situations
where this comes up. I don't remember how I fixed the problem last time,
though.
James
___
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
On Tue, Apr 12, 2011 at 2:13 PM, James Bigler jamesbig...@gmail.com wrote:
On Mon, Jan 17, 2011 at 11:27 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Jan 17, 2011, at 1:23 PM, Eric Noulard wrote:
2011/1/17 Michael Jackson mike.jack...@bluequartz.net:
I have the following code:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win64)
elseif( ${CMAKE_SIZEOF_VOID_P} EQUAL 4 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win32)
else()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Unknown)
endif()
I properly generate VS 2008 Win64 projects. Everything builds fine.
When I build the PACKAGE project I get a zip file with -Unknown in the
name. This will usually configure OK the first time or so, ie, I get a Zip
file name with -Win64 but after a few more configs this seems to revert
back to Unknown. Searching the CMakeCache.txt file for
CMAKE_SIZEOF_VOID_P comes up empty. Is this some sort of temporary
variable?
Shouldn't be temporary just not in cache.
Do I need to store it in my own cache variable somewhere?
I don't think you should.
Looks like a bug to me, how come CMAKE_SIZEOF_VOID_P
would it be defined sometimes but not **always**...
need to dive into the source of this definition, may be it is not always
defined because it is indirectly defined in the chain of CMake
processing due
to CMake cache.
By the way shouldn't you use
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
instead of
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
from the doc I think EQUAL is for values whereas STREQUAL is for string.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
It seems like if I start with a clean build directory then
CMAKE_SIZEOF_VOID_P will be the proper value for the environment I am
running in. But then after a while (many runs of CMake) the value seems to
get lost or otherwise is NOT in the cache any longer. Kind of odd really.
You are probably right about the improper use of the if command. I never
really know which one to use and when something does not work when I _think_
it really *should* work then I start trying all sorts of stuff.
Maybe someone else has some ideas as to why CMAKE_SIZEOF_VOID_P might not
be defined.
___
Mike Jackson www.bluequartz.net
___
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
I've also seen this, and I would appreciate if anyone else who experiences
this could chime in, so that we might be able to start profiling situations
where this comes up. I don't remember how I fixed the problem last time,
though.
James
Maybe you can base the package name by testing the generator name. As for
the pointer size, I use:
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
Regards,
Juan
___
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
On Tue, Apr 12, 2011 at 1:27 PM, j s j.s4...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:13 PM, James Bigler jamesbig...@gmail.comwrote:
On Mon, Jan 17, 2011 at 11:27 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Jan 17, 2011, at 1:23 PM, Eric Noulard wrote:
2011/1/17 Michael Jackson mike.jack...@bluequartz.net:
I have the following code:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win64)
elseif( ${CMAKE_SIZEOF_VOID_P} EQUAL 4 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win32)
else()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Unknown)
endif()
I properly generate VS 2008 Win64 projects. Everything builds fine.
When I build the PACKAGE project I get a zip file with -Unknown in the
name. This will usually configure OK the first time or so, ie, I get a Zip
file name with -Win64 but after a few more configs this seems to revert
back to Unknown. Searching the CMakeCache.txt file for
CMAKE_SIZEOF_VOID_P comes up empty. Is this some sort of temporary
variable?
Shouldn't be temporary just not in cache.
Do I need to store it in my own cache variable somewhere?
I don't think you should.
Looks like a bug to me, how come CMAKE_SIZEOF_VOID_P
would it be defined sometimes but not **always**...
need to dive into the source of this definition, may be it is not
always
defined because it is indirectly defined in the chain of CMake
processing due
to CMake cache.
By the way shouldn't you use
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
instead of
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
from the doc I think EQUAL is for values whereas STREQUAL is for
string.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
It seems like if I start with a clean build directory then
CMAKE_SIZEOF_VOID_P will be the proper value for the environment I am
running in. But then after a while (many runs of CMake) the value seems to
get lost or otherwise is NOT in the cache any longer. Kind of odd really.
You are probably right about the improper use of the if command. I
never really know which one to use and when something does not work when I
_think_ it really *should* work then I start trying all sorts of stuff.
Maybe someone else has some ideas as to why CMAKE_SIZEOF_VOID_P might not
be defined.
___
Mike Jackson www.bluequartz.net
___
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
I've also seen this, and I would appreciate if anyone else who experiences
this could chime in, so that we might be able to start profiling situations
where this comes up. I don't remember how I fixed the problem last time,
though.
James
Maybe you can base the package name by testing the generator name. As for
the pointer size, I use:
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
Regards,
Juan
Yeah, the problem is that CMAKE_SIZEOF_VOID_P's value disappears (i.e. as if
the variable hasn't been defined). This would make that test fail
regardless of whether it was a 32 or 64 bit build.
James
___
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
On Tue, Apr 12, 2011 at 4:07 PM, James Bigler jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 1:27 PM, j s j.s4...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:13 PM, James Bigler jamesbig...@gmail.comwrote:
On Mon, Jan 17, 2011 at 11:27 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Jan 17, 2011, at 1:23 PM, Eric Noulard wrote:
2011/1/17 Michael Jackson mike.jack...@bluequartz.net:
I have the following code:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win64)
elseif( ${CMAKE_SIZEOF_VOID_P} EQUAL 4 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win32)
else()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Unknown)
endif()
I properly generate VS 2008 Win64 projects. Everything builds fine.
When I build the PACKAGE project I get a zip file with -Unknown in the
name. This will usually configure OK the first time or so, ie, I get a Zip
file name with -Win64 but after a few more configs this seems to revert
back to Unknown. Searching the CMakeCache.txt file for
CMAKE_SIZEOF_VOID_P comes up empty. Is this some sort of temporary
variable?
Shouldn't be temporary just not in cache.
Do I need to store it in my own cache variable somewhere?
I don't think you should.
Looks like a bug to me, how come CMAKE_SIZEOF_VOID_P
would it be defined sometimes but not **always**...
need to dive into the source of this definition, may be it is not
always
defined because it is indirectly defined in the chain of CMake
processing due
to CMake cache.
By the way shouldn't you use
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
instead of
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
from the doc I think EQUAL is for values whereas STREQUAL is for
string.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
It seems like if I start with a clean build directory then
CMAKE_SIZEOF_VOID_P will be the proper value for the environment I am
running in. But then after a while (many runs of CMake) the value seems to
get lost or otherwise is NOT in the cache any longer. Kind of odd really.
You are probably right about the improper use of the if command. I
never really know which one to use and when something does not work when I
_think_ it really *should* work then I start trying all sorts of stuff.
Maybe someone else has some ideas as to why CMAKE_SIZEOF_VOID_P might
not be defined.
___
Mike Jackson www.bluequartz.net
___
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
I've also seen this, and I would appreciate if anyone else who
experiences this could chime in, so that we might be able to start profiling
situations where this comes up. I don't remember how I fixed the problem
last time, though.
James
Maybe you can base the package name by testing the generator name. As for
the pointer size, I use:
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
Regards,
Juan
Yeah, the problem is that CMAKE_SIZEOF_VOID_P's value disappears (i.e. as
if the variable hasn't been defined). This would make that test fail
regardless of whether it was a 32 or 64 bit build.
James
___
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
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.
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
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 ___ 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
On Apr 12, 2011, at 4:24 PM, Bill Hoffman 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 You guys can slap me upside the head after this but I think this is what is going wrong. Sometimes Visual Studio and CMake just don't seem to be be playing well together so I will go into the build folder and delete EVERYTHING except the CMakeCache.txt file and then just rerun cmake. So maybe that is what is going wrong? Dunno. I'll try it a bit later after my current deadline. Mike Jackson ___ 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
[CMake] Properly Detecting Win64
I have the following code:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win64)
elseif( ${CMAKE_SIZEOF_VOID_P} EQUAL 4 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win32)
else()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Unknown)
endif()
I properly generate VS 2008 Win64 projects. Everything builds fine. When I
build the PACKAGE project I get a zip file with -Unknown in the name. This
will usually configure OK the first time or so, ie, I get a Zip file name with
-Win64 but after a few more configs this seems to revert back to Unknown.
Searching the CMakeCache.txt file for CMAKE_SIZEOF_VOID_P comes up empty.
Is this some sort of temporary variable? Do I need to store it in my own cache
variable somewhere?
Thanks for any help
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@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
Re: [CMake] Properly Detecting Win64
2011/1/17 Michael Jackson mike.jack...@bluequartz.net:
I have the following code:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win64)
elseif( ${CMAKE_SIZEOF_VOID_P} EQUAL 4 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win32)
else()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Unknown)
endif()
I properly generate VS 2008 Win64 projects. Everything builds fine. When I
build the PACKAGE project I get a zip file with -Unknown in the name.
This will usually configure OK the first time or so, ie, I get a Zip file
name with -Win64 but after a few more configs this seems to revert back to
Unknown. Searching the CMakeCache.txt file for CMAKE_SIZEOF_VOID_P
comes up empty. Is this some sort of temporary variable?
Shouldn't be temporary just not in cache.
Do I need to store it in my own cache variable somewhere?
I don't think you should.
Looks like a bug to me, how come CMAKE_SIZEOF_VOID_P
would it be defined sometimes but not **always**...
need to dive into the source of this definition, may be it is not always
defined because it is indirectly defined in the chain of CMake processing due
to CMake cache.
By the way shouldn't you use
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
instead of
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
from the doc I think EQUAL is for values whereas STREQUAL is for string.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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
On Jan 17, 2011, at 1:23 PM, Eric Noulard wrote:
2011/1/17 Michael Jackson mike.jack...@bluequartz.net:
I have the following code:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win64)
elseif( ${CMAKE_SIZEOF_VOID_P} EQUAL 4 )
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Win32)
else()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-Unknown)
endif()
I properly generate VS 2008 Win64 projects. Everything builds fine. When I
build the PACKAGE project I get a zip file with -Unknown in the name.
This will usually configure OK the first time or so, ie, I get a Zip file
name with -Win64 but after a few more configs this seems to revert back to
Unknown. Searching the CMakeCache.txt file for CMAKE_SIZEOF_VOID_P
comes up empty. Is this some sort of temporary variable?
Shouldn't be temporary just not in cache.
Do I need to store it in my own cache variable somewhere?
I don't think you should.
Looks like a bug to me, how come CMAKE_SIZEOF_VOID_P
would it be defined sometimes but not **always**...
need to dive into the source of this definition, may be it is not always
defined because it is indirectly defined in the chain of CMake processing
due
to CMake cache.
By the way shouldn't you use
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
instead of
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8 )
from the doc I think EQUAL is for values whereas STREQUAL is for string.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
It seems like if I start with a clean build directory then CMAKE_SIZEOF_VOID_P
will be the proper value for the environment I am running in. But then after a
while (many runs of CMake) the value seems to get lost or otherwise is NOT in
the cache any longer. Kind of odd really.
You are probably right about the improper use of the if command. I never
really know which one to use and when something does not work when I _think_ it
really *should* work then I start trying all sorts of stuff.
Maybe someone else has some ideas as to why CMAKE_SIZEOF_VOID_P might not be
defined.
___
Mike Jackson www.bluequartz.net
___
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
