[cmake-developers] Build rules for CMakeLists.txt files
What would it take to remove the build rules on the CMakeLists.txt files in Visual Studio? They are causing me no end of grief with the CUDA tools. Basically what happens is that the CMakeLists.txt files are getting compiled after the CUDA rules causing each and every project to trigger a reconfigure event which loads the plugin dialog box. I'm wanting the reconfigure even to happen only during the ZERO_CHECK phase (e.g. once for every 'build it' command). At one point we had discussed the fact that having a build rule on the CMakeLists.txt files is generally a Bad Idea when dealing with parallel builds, but it is even more unbearable now that VS 2010 seems to be running the CMakeLists.txt build rule after the CUDA ones. Thanks, James ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Build rules for CMakeLists.txt files
I also just noticed that if I set CMAKE_SUPPRESS_REGENERATION, then the CMakeLists.txt files don't get added to the projects. I wonder how hard it would be to just not add build rules to the CMakeLists.txt files.. James On Tue, Aug 9, 2011 at 2:48 PM, James Bigler jamesbig...@gmail.com wrote: What would it take to remove the build rules on the CMakeLists.txt files in Visual Studio? They are causing me no end of grief with the CUDA tools. Basically what happens is that the CMakeLists.txt files are getting compiled after the CUDA rules causing each and every project to trigger a reconfigure event which loads the plugin dialog box. I'm wanting the reconfigure even to happen only during the ZERO_CHECK phase (e.g. once for every 'build it' command). At one point we had discussed the fact that having a build rule on the CMakeLists.txt files is generally a Bad Idea when dealing with parallel builds, but it is even more unbearable now that VS 2010 seems to be running the CMakeLists.txt build rule after the CUDA ones. Thanks, James ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Build rules for CMakeLists.txt files
I guess a different question I should be asking is why is the CMakeLists.txt build rule running after my other custom rules. It seems to me that the CMakeLists.txt build rule should *always* be the first thing to build in a given project. James On Tue, Aug 9, 2011 at 4:06 PM, James Bigler jamesbig...@gmail.com wrote: I also just noticed that if I set CMAKE_SUPPRESS_REGENERATION, then the CMakeLists.txt files don't get added to the projects. I wonder how hard it would be to just not add build rules to the CMakeLists.txt files.. James On Tue, Aug 9, 2011 at 2:48 PM, James Bigler jamesbig...@gmail.comwrote: What would it take to remove the build rules on the CMakeLists.txt files in Visual Studio? They are causing me no end of grief with the CUDA tools. Basically what happens is that the CMakeLists.txt files are getting compiled after the CUDA rules causing each and every project to trigger a reconfigure event which loads the plugin dialog box. I'm wanting the reconfigure even to happen only during the ZERO_CHECK phase (e.g. once for every 'build it' command). At one point we had discussed the fact that having a build rule on the CMakeLists.txt files is generally a Bad Idea when dealing with parallel builds, but it is even more unbearable now that VS 2010 seems to be running the CMakeLists.txt build rule after the CUDA ones. Thanks, James ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Overriding C compiler flags in CMakeLists files
Hello,
I'm trying to compile out-of-source an embedded C application using CMake
and MinGW and to use specific compiler flags for some source files.
I tried the approach described in
http://www.cmake.org/pipermail/cmake/2011-April/043703.html but it didn't
work for me. I'm describing below what i've done, maybe someone highlights
what i did wrong:
Project structure:
Top_Dir
|-- Build (from where I launch cmake)
| |-- Output_Dir
| |-- Toolchain.cmake
| |-- build.bat
|-- Sources
|-- Module1
| |-- module1.c
| |-- module1.h
| |-- CMakeLists.txt [1]
|-- Module2
| |-- module2.c
| |-- module2.h
| |-- CMakeLists.txt [2]
|-- Module3
| |-- module3.c
| |-- module3.h
| |-- CMakeLists.txt [3]
|-- CMakeLists.txt [0]
*build.bat*
mkdir Output_Dir
cd Output_Dir
cmake ../../Sources -DCMAKE_TOOLCHAIN_FILE=../Toolchain.cmake -GMinGW
Makefiles
*CMakeLists.txt [0]*
cmake_minimum_required( VERSION 2.8 )
project( My_Project C ASM )
include_directories(
Module1
Module2
Module3
)
add_subdirectory( Module1 )
add_subdirectory( Module2 )
add_subdirectory( Module3)
set( USER_C_COMPILER_FLAGS
c_flag1
c_flag2
c_flag3
)
foreach( flag ${USER_C_COMPILER_FLAGS} )
set( USER_C_COMPILER_FLAGS_GENERAL ${USER_C_COMPILER_FLAGS_GENERAL}
${flag} )
endforeach( flag ${USER_C_COMPILER_FLAGS} )
*set( CMAKE_C_FLAGS ${USER_C_COMPILER_FLAGS_GENERAL} )*
add_definitions(
-D DEF1
-D DEF2
-D DEF3
)
set( USER_LINKER_FLAGS
link_flag1
link_flag2
link_flag3
)
set( USER_TMP_LINKER_FLAGS )
foreach( flag ${USER_LINKER_FLAGS} )
set( USER_TMP_LINKER_FLAGS ${USER_TMP_LINKER_FLAGS} ${flag} )
endforeach( flag ${USER_LINKER_FLAGS} )
set( CMAKE_EXE_LINKER_FLAGS ${USER_TMP_LINKER_FLAGS} )
set( PRJ_SOURCES
Module1/module1.c
Module2/module2.c
Module3/module3.c
)
add_executable( My_Exec ${PRJ_SOURCES} )
set( CMAKE_VERBOSE_MAKEFILE ON )
I tried to place in any of the leaf CMakeLists.txt files ([1][2][3])
statements like
set(USER_C_COMPILER_FLAGS_LOCAL c_loc_flag1 c_loc_flag2 c_loc_flag3)
set( CMAKE_C_FLAGS ${USER_C_COMPILER_FLAGS_LOCAL} )
and I expected to see different compiler flags for the sources in the
respective directory, but instead ALL the sources were compiled with the
flags defined in CMakeLists.txt[0] top level file.
What I did wrong? I clearly miss something in the inheritance mechanisms of
CMake.
In Cmake Platform and Compiler folders i created the custom platform and
compiler files with directives like:
set( CMAKE_C_LINK_EXECUTABLE
${USER_CONFIG_LINKER} LINK_FLAGS OBJECTS -o TARGET
${USER_CONFIG_CONVERTER} TARGET -o TARGET
)
set( CMAKE_ASM_SOURCE_FILE_EXTENSIONS asm ASM )
set( CMAKE_ASM_OUTPUT_EXTENSION .obj )
set( CMAKE_ASM_COMPILE_OBJECT CMAKE_ASM_COMPILER FLAGS SOURCE -o
OBJECT )
set( CMAKE_ASM_FLAGS_INIT a list of ASM flags )
to make the assembler work of ASM files and to use the custom linker and
executable converter specific for the compiler kit I use.
Thanks,
Andrei
___
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] CMAKE_ROOT issue in scratchbox, N9(50)
Hi Alex,
Which version of cmake is this ?
Is this 2.8.5rcX or trunk ?
Then it might be the new multiarch support feature maybe.
2.8.4 and it will probably not even change on Harmattan
Uh.
The part where you install *.cmake files into ${CMAKE_ROOT}/Modules/ is really
bad. Remove it. You should never ever do that.
The user may simply use another version of cmake, then they won't be found, so
you can't rely on them at all in any way.
Not sure what you mean by this, but the proposed alternative way seems
to also be a cmake version dependent deal. From the documentation:
...CMake 2.6 introduced support for exporting targets from one
project and importing them into another However I think it is
achievable...Not sure about the version difference aforementioned.
FindGluon.cmake is supposed to be there, so you can rely on it and it will
tell you where Gluon is installed or if it's not installed.
It's like putting a treasure map just next to the treasure.
Once you find the map (or FindGluon.cmake), you already found the treaure
(Gluon) itself, no need to search for it anymore.
Instead Gluon should install a GluonConfig.cmake file.
Mmm, so it seems a bit controversial to me. You mentioned that above
it is bad if the map is nearby the treasure. However, it seems to
still be the situation since Gluon will install it. I thought that the
only way is that if it is independently installed from Gluon since
that way, it exists anytime. This is still a bit confusing to me.
Could you please clarify ? Thank you!
Best Regards,
Laszlo Papp
___
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] CMAKE_ROOT issue in scratchbox, N9(50)
On Tue 09 Aug 2011 04:04:59 PM CEST, Laszlo Papp wrote:
Hi Alex,
Which version of cmake is this ?
Is this 2.8.5rcX or trunk ?
Then it might be the new multiarch support feature maybe.
2.8.4 and it will probably not even change on Harmattan
Uh.
The part where you install *.cmake files into ${CMAKE_ROOT}/Modules/ is
really
bad. Remove it. You should never ever do that.
The user may simply use another version of cmake, then they won't be found,
so
you can't rely on them at all in any way.
Not sure what you mean by this, but the proposed alternative way seems
to also be a cmake version dependent deal. From the documentation:
...CMake 2.6 introduced support for exporting targets from one
project and importing them into another However I think it is
achievable...Not sure about the version difference aforementioned.
FindGluon.cmake is supposed to be there, so you can rely on it and it will
tell you where Gluon is installed or if it's not installed.
It's like putting a treasure map just next to the treasure.
Once you find the map (or FindGluon.cmake), you already found the treaure
(Gluon) itself, no need to search for it anymore.
Instead Gluon should install a GluonConfig.cmake file.
Mmm, so it seems a bit controversial to me. You mentioned that above
it is bad if the map is nearby the treasure. However, it seems to
still be the situation since Gluon will install it. I thought that the
only way is that if it is independently installed from Gluon since
that way, it exists anytime. This is still a bit confusing to me.
Could you please clarify ? Thank you!
Best Regards,
Laszlo Papp
What Alex tried to tell you is that you are installing the *.cmake
files in the _wrong_ place. The install location you chose is polluting
the CMake installation! Also, FindXXX.cmake files are intended for
software that is _not_ built by CMake. Projects built by CMake should
install XXXConfig.cmake files into well-defined directories (read this:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package,
in particular the section about the Config mode). For a simple
example, you might want to look into the Wiki:
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file.
However, notice that the Wiki is a bit outdated (I can say that, I
wrote that page ;-)) in that it configures FooConfig.cmake twice, once
for use from the build tree and once from the install tree. You can do
without this duplication if you do some magic in FooConfig.cmake that
detects whether it is located inside the build tree (by e.g. verifying
whether the file CMakeCache.txt exists next to it).
HTH
Michael
___
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] Overriding C compiler flags in CMakeLists files
On Tue 09 Aug 2011 04:28:51 PM CEST, Tim Gallagher wrote:
In your leaf CMakeLists.txt, try doing:
set_source_files_properties(${SOURCE_FILES} PROPERTIES COMPILE_FLAGS
${LOCAL_COMPILE_FLAGS})
where ${SOURCE_FILES} is a list of the files in the directory and
${LOCAL_COMPILE_FLAGS} is the list of flags for those files.
Ideally you would want to set this for the entire directory, but
according to the documentation, the COMPILE_FLAGS property doesn't exist
for directories.
Tim
Setting a directory property wouldn't help, since the directory
property is inherited by the target, not the source files. And since
the target lives in the top-level CMakeLists.txt file, the directory
properties wouldn't come into play at all.
Michael
___
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] Overriding C compiler flags in CMakeLists files
Interesting -- I guess this is sort of off topic from the original post, but
that brings up a question:
How does setting the COMPILE_DEFINITIONS on the directory work then? I was
under the impression (not having tried it) that those definitions would only be
added when compiling files contained in the directory. I assumed COMPILE_FLAGS
could, if it existed, operate the same way.
Tim
- Original Message -
From: Michael Wild them...@gmail.com
To: cmake@cmake.org
Sent: Tuesday, August 9, 2011 10:32:58 AM
Subject: Re: [CMake] Overriding C compiler flags in CMakeLists files
On Tue 09 Aug 2011 04:28:51 PM CEST, Tim Gallagher wrote:
In your leaf CMakeLists.txt, try doing:
set_source_files_properties(${SOURCE_FILES} PROPERTIES COMPILE_FLAGS
${LOCAL_COMPILE_FLAGS})
where ${SOURCE_FILES} is a list of the files in the directory and
${LOCAL_COMPILE_FLAGS} is the list of flags for those files.
Ideally you would want to set this for the entire directory, but
according to the documentation, the COMPILE_FLAGS property doesn't exist
for directories.
Tim
Setting a directory property wouldn't help, since the directory
property is inherited by the target, not the source files. And since
the target lives in the top-level CMakeLists.txt file, the directory
properties wouldn't come into play at all.
Michael
___
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] Overriding C compiler flags in CMakeLists files
Well, directory properties are used by _targets_ defined in that
directory. It doesn't matter where the sources are located.
Michael
On 08/09/2011 04:36 PM, Tim Gallagher wrote:
Interesting -- I guess this is sort of off topic from the original post, but
that brings up a question:
How does setting the COMPILE_DEFINITIONS on the directory work then? I was
under the impression (not having tried it) that those definitions would only
be added when compiling files contained in the directory. I assumed
COMPILE_FLAGS could, if it existed, operate the same way.
Tim
- Original Message -
From: Michael Wild them...@gmail.com
To: cmake@cmake.org
Sent: Tuesday, August 9, 2011 10:32:58 AM
Subject: Re: [CMake] Overriding C compiler flags in CMakeLists files
On Tue 09 Aug 2011 04:28:51 PM CEST, Tim Gallagher wrote:
In your leaf CMakeLists.txt, try doing:
set_source_files_properties(${SOURCE_FILES} PROPERTIES COMPILE_FLAGS
${LOCAL_COMPILE_FLAGS})
where ${SOURCE_FILES} is a list of the files in the directory and
${LOCAL_COMPILE_FLAGS} is the list of flags for those files.
Ideally you would want to set this for the entire directory, but
according to the documentation, the COMPILE_FLAGS property doesn't exist
for directories.
Tim
Setting a directory property wouldn't help, since the directory
property is inherited by the target, not the source files. And since
the target lives in the top-level CMakeLists.txt file, the directory
properties wouldn't come into play at all.
Michael
___
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] Wiki spam
Hi, I just noticed that some spam pages seem to have been inserted into the wiki using these user accounts: http://www.cmake.org/Wiki/Special:Contributions/Carinsurancecarinsurancequotes http://www.cmake.org/Wiki/Special:Contributions/Sarawilliam30 http://www.cmake.org/Wiki/Special:Contributions/WalterMosley http://www.cmake.org/Wiki/Special:Contributions/Janyrobert23 http://www.cmake.org/Wiki/Special:Contributions/Rozer456 http://www.cmake.org/Wiki/Special:Contributions/Jason85clark Also, one can find lots of spam pages via the orphaned pages... Is there a preferred way how to deal with wiki-spam one encounters? Kind regards, Johannes ___ 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] Overriding C compiler flags in CMakeLists files
On 08/09/2011 04:43 PM, Michael Wild wrote:
Well, directory properties are used by _targets_ defined in that
directory. It doesn't matter where the sources are located.
Michael
Additionally, setting a source property in the leaf CMakeLists.txt
files as it has been suggested in this thread earlier wouldn't work
also since such properties apply to source files for targets defined
in the same CMakeLists.txt only. As the target is defined in the top-
level CMakeLists.txt, any source property set in a subdirectory's
CMakeLists.txt won't take effect.
To revisit Andrei's concern: As your target is defined in the top-level
CMakeLists.txt, only settings which are valid in this file apply to the
My_Exec target, i.e. they must be defined in this CMakeLists.txt since
there's no superior one to inherit from. Thus, you should imply source
file properties, e.g. COMPILE_FLAGS, on the source files from within
the top-level CMakeLists.txt. As an alternative, in each of your sub-
directories, you might define a static library target built from the
respective source files and link your top-level target against these
libraries, provided your toolchain supports it. In this manner, you
can define fine-grained target/directory-specific compilation flags,
and linking against a static library is usually quite the same as
incorporating the library's object files immediately.
'hope that helps.
Regards,
Michael
On 08/09/2011 04:36 PM, Tim Gallagher wrote:
Interesting -- I guess this is sort of off topic from the original post, but
that brings up a question:
How does setting the COMPILE_DEFINITIONS on the directory work then? I was
under the impression (not having tried it) that those definitions would only
be added when compiling files contained in the directory. I assumed
COMPILE_FLAGS could, if it existed, operate the same way.
Tim
- Original Message -
From: Michael Wild them...@gmail.com
To: cmake@cmake.org
Sent: Tuesday, August 9, 2011 10:32:58 AM
Subject: Re: [CMake] Overriding C compiler flags in CMakeLists files
On Tue 09 Aug 2011 04:28:51 PM CEST, Tim Gallagher wrote:
In your leaf CMakeLists.txt, try doing:
set_source_files_properties(${SOURCE_FILES} PROPERTIES COMPILE_FLAGS
${LOCAL_COMPILE_FLAGS})
where ${SOURCE_FILES} is a list of the files in the directory and
${LOCAL_COMPILE_FLAGS} is the list of flags for those files.
Ideally you would want to set this for the entire directory, but
according to the documentation, the COMPILE_FLAGS property doesn't exist
for directories.
Tim
Setting a directory property wouldn't help, since the directory
property is inherited by the target, not the source files. And since
the target lives in the top-level CMakeLists.txt file, the directory
properties wouldn't come into play at all.
Michael
___
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] Bug fix requests for the *next* release of CMake...
Probably too late now and there isn't a bug filed so far as I know, but one
thing I would love to see added to cmake is an append command so that lines
like this:
set(CMAKE_EXE_LINKER_FLAGS_RELEASE ${CMAKE_EXE_LINKER_FLAGS_RELEASE}
/INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when appending. I know
you can define a macro or function to do this but I just feel that it should
be supported out of the box as it would make CMakeLists.txt files more
readable.
--
Glenn
___
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] how to add additional linker options
Hello, I need to add to provide additional linker options to the program from within my CMakeLists.txt targeted at MSVC platform. In particular, I would like to add the /FORCE:Multiply option to the linker. How would I go about doing this? Also, how would I set the options to suppress any (all) warnings generated? Thanks, Vinay ___ 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] Not matching versions of MSVC Runtime Libraries in Manifest
Not sure if this is a CMake issue or not but I'll give it a shot. I am packaging up my application using CPack (zip) and all seems fine. I get the MSVC runtime libraries copied and the manifest file created and all seems to run just fine. If I use Dependency Walker to look at exactly _which_ C/C++ runtime DLLs are being loaded it seems to indicate a newer version than what the manifest is saying. My Application seems to be requesting version 9.0.21022.8 in its manifest and in the executable itself (Embedded Manifest) but Dependency Walker says it is really loading the 9.0.30729.490 version from the winsxs folder. I am still really new to this with Visual Studio so I am not sure if I am doing something incorrect when writing the CPack code, something in Visual Studio, how I compiled all the dependent libraries or what but any help or pushes in a better direction would be greatly appreciated. System: Windows 7 X64 Pro. Visual Studio 2008. Compiling everything as 64 bit. The actual executables can be downloaded from http://dream3d.bluequartz.net. Thanks in advance. ___ 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
[CMake] FindThreads.cmake for Android
Hi all, I noticed that FindThreads.cmake does not detect that Bionic (the Android C library) has pthreads built-in. Adding the following snippet to the front of the pthreads section (after pthread.h is found) in FindThreads.cmake seems to handle this case correctly. CHECK_SYMBOL_EXISTS (pthread_create pthread.h CMAKE_HAVE_BUILTIN_PTHREAD_CREATE) IF (CMAKE_HAVE_BUILTIN_PTHREAD_CREATE) SET(CMAKE_USE_PTHREADS_INIT 1) SET(CMAKE_THREAD_LIBS_INIT ) SET(CMAKE_HAVE_THREADS_LIBRARY 1) SET(Threads_FOUND TRUE) ENDIF () Should I file this in Mantis? Gregory Peele, Jr. Senior Scientist Applied Research Associates, Inc. Central Florida Division ___ 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] FindThreads.cmake for Android
Please do not submit an entry to the bug tracker. It's a duplicate of these two existing entries: http://public.kitware.com/Bug/view.php?id=7830 http://public.kitware.com/Bug/view.php?id=11333 Monitor those to see when they're fixed. Presently, they're on the roadmap for the upcoming CMake 2.8.6 release. Thanks, David On Tue, Aug 9, 2011 at 1:28 PM, Gregory Peele ARA/CFD gpe...@ara.com wrote: Hi all, I noticed that FindThreads.cmake does not detect that Bionic (the Android C library) has pthreads built-in. Adding the following snippet to the front of the pthreads section (after pthread.h is found) in FindThreads.cmake seems to handle this case correctly. CHECK_SYMBOL_EXISTS (pthread_create pthread.h CMAKE_HAVE_BUILTIN_PTHREAD_CREATE) IF (CMAKE_HAVE_BUILTIN_PTHREAD_CREATE) SET(CMAKE_USE_PTHREADS_INIT 1) SET(CMAKE_THREAD_LIBS_INIT ) SET(CMAKE_HAVE_THREADS_LIBRARY 1) SET(Threads_FOUND TRUE) ENDIF () Should I file this in Mantis? Gregory Peele, Jr. Senior Scientist Applied Research Associates, Inc. Central Florida Division ___ 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] Not matching versions of MSVC Runtime Libraries in Manifest
Yes, I think part of the issue is what is mentioned and I do have plugins (Qt based) and have taken the steps he lays out. But I am still curious as to why Dependency Walker says it is using one version of the runtime libraries when the Manifest (both external and embedded) says to use another. I am probably just missing something basic in all of this. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Aug 9, 2011, at 3:07 PM, Michael Wild wrote: On Tue 09 Aug 2011 06:48:34 PM CEST, Michael Jackson wrote: Not sure if this is a CMake issue or not but I'll give it a shot. I am packaging up my application using CPack (zip) and all seems fine. I get the MSVC runtime libraries copied and the manifest file created and all seems to run just fine. If I use Dependency Walker to look at exactly _which_ C/C++ runtime DLLs are being loaded it seems to indicate a newer version than what the manifest is saying. My Application seems to be requesting version 9.0.21022.8 in its manifest and in the executable itself (Embedded Manifest) but Dependency Walker says it is really loading the 9.0.30729.490 version from the winsxs folder. I am still really new to this with Visual Studio so I am not sure if I am doing something incorrect when writing the CPack code, something in Visual Studio, how I compiled all the dependent libraries or what but any help or pushes in a better direction would be greatly appreciated. System: Windows 7 X64 Pro. Visual Studio 2008. Compiling everything as 64 bit. The actual executables can be downloaded from http://dream3d.bluequartz.net. Thanks in advance. Not sure, but could it be the issue mentioned in Bills blog? http://www.kitware.com/blog/home/post/4 Michael ___ 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] Not matching versions of MSVC Runtime Libraries in Manifest
Here's my (not so complete) understanding... Public assemblies are searched before private ones. http://msdn.microsoft.com/en-us/library/aa374224(v=vs.85).aspx So, on your machine, you have the required CRT libraires in the winsxs folder. You also have a redirection that says to use a newer CRT library if a particular older one is requested. If another machine that you copy this software to doesn't have a shared CRT that will work, it falls back to the one you copied next to your application. So its a way to get updates and bug fixes to the CRT via windows updates, but still allow your application to work on older machines without the newer dlls, by using the ones you provided. Clint - Original Message - Yes, I think part of the issue is what is mentioned and I do have plugins (Qt based) and have taken the steps he lays out. But I am still curious as to why Dependency Walker says it is using one version of the runtime libraries when the Manifest (both external and embedded) says to use another. I am probably just missing something basic in all of this. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Aug 9, 2011, at 3:07 PM, Michael Wild wrote: On Tue 09 Aug 2011 06:48:34 PM CEST, Michael Jackson wrote: Not sure if this is a CMake issue or not but I'll give it a shot. I am packaging up my application using CPack (zip) and all seems fine. I get the MSVC runtime libraries copied and the manifest file created and all seems to run just fine. If I use Dependency Walker to look at exactly _which_ C/C++ runtime DLLs are being loaded it seems to indicate a newer version than what the manifest is saying. My Application seems to be requesting version 9.0.21022.8 in its manifest and in the executable itself (Embedded Manifest) but Dependency Walker says it is really loading the 9.0.30729.490 version from the winsxs folder. I am still really new to this with Visual Studio so I am not sure if I am doing something incorrect when writing the CPack code, something in Visual Studio, how I compiled all the dependent libraries or what but any help or pushes in a better direction would be greatly appreciated. System: Windows 7 X64 Pro. Visual Studio 2008. Compiling everything as 64 bit. The actual executables can be downloaded from http://dream3d.bluequartz.net. Thanks in advance. Not sure, but could it be the issue mentioned in Bills blog? http://www.kitware.com/blog/home/post/4 Michael ___ 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
[CMake] access absolute path of parent directory
Hello, I've been trying to access the parent directory by using CMakeLists.txt. However, the ../ or .. or /../ notations don't access said parent directory. Thank you, Vinay ___ 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] Not matching versions of MSVC Runtime Libraries in Manifest
On Tue, Aug 9, 2011 at 3:27 PM, clin...@elemtech.com wrote: Here's my (not so complete) understanding... Public assemblies are searched before private ones. http://msdn.microsoft.com/en-us/library/aa374224(v=vs.85).aspx So, on your machine, you have the required CRT libraires in the winsxs folder. You also have a redirection that says to use a newer CRT library if a particular older one is requested. If another machine that you copy this software to doesn't have a shared CRT that will work, it falls back to the one you copied next to your application. So its a way to get updates and bug fixes to the CRT via windows updates, but still allow your application to work on older machines without the newer dlls, by using the ones you provided. Clint - Original Message - Yes, I think part of the issue is what is mentioned and I do have plugins (Qt based) and have taken the steps he lays out. But I am still curious as to why Dependency Walker says it is using one version of the runtime libraries when the Manifest (both external and embedded) says to use another. I am probably just missing something basic in all of this. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Aug 9, 2011, at 3:07 PM, Michael Wild wrote: On Tue 09 Aug 2011 06:48:34 PM CEST, Michael Jackson wrote: Not sure if this is a CMake issue or not but I'll give it a shot. I am packaging up my application using CPack (zip) and all seems fine. I get the MSVC runtime libraries copied and the manifest file created and all seems to run just fine. If I use Dependency Walker to look at exactly _which_ C/C++ runtime DLLs are being loaded it seems to indicate a newer version than what the manifest is saying. My Application seems to be requesting version 9.0.21022.8 in its manifest and in the executable itself (Embedded Manifest) but Dependency Walker says it is really loading the 9.0.30729.490 version from the winsxs folder. I am still really new to this with Visual Studio so I am not sure if I am doing something incorrect when writing the CPack code, something in Visual Studio, how I compiled all the dependent libraries or what but any help or pushes in a better direction would be greatly appreciated. System: Windows 7 X64 Pro. Visual Studio 2008. Compiling everything as 64 bit. The actual executables can be downloaded from http://dream3d.bluequartz.net. Thanks in advance. Not sure, but could it be the issue mentioned in Bills blog? http://www.kitware.com/blog/home/post/4 Michael ___ 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 Thanks for this pointer, Clinton. I'll add a comment to Bill's blog article that also points to this Microsoft page... Good reference. :-) 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] access absolute path of parent directory
I've been trying to access the parent directory by using CMakeLists.txt. However, the ../ or .. or /../ notations don't access said parent directory. Can you show a small example? I know this has worked for me. John ___ 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] append command
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as I know, but one
thing I would love to see added to cmake is an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_RELEASE ${CMAKE_EXE_LINKER_FLAGS_RELEASE}
/INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when appending. I know
you can define a macro or function to do this but I just
feel that it should be supported out of the box as it would make CMakeLists.txt
files more readable.
Hi Glenn:
I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.
It appears what you want is the list APPEND command for
blank-delimited strings. But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list. Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).
I think most would reject the idea of having two parallel list systems
with different delimiters so here is one possibility.
For now just stick to list functionality, e.g.,
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
and then change the semicolon delimiters to blanks using
strings(REGEX REPLACE ...)
once you have the list completely assembled. Of course, that will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to preserve
backwards compatibility.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
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] Not matching versions of MSVC Runtime Libraries in Manifest
Very cool! +1 On Tue, Aug 9, 2011 at 3:28 PM, David Cole david.c...@kitware.com wrote: On Tue, Aug 9, 2011 at 3:27 PM, clin...@elemtech.com wrote: Here's my (not so complete) understanding... Public assemblies are searched before private ones. http://msdn.microsoft.com/en-us/library/aa374224(v=vs.85).aspx So, on your machine, you have the required CRT libraires in the winsxs folder. You also have a redirection that says to use a newer CRT library if a particular older one is requested. If another machine that you copy this software to doesn't have a shared CRT that will work, it falls back to the one you copied next to your application. So its a way to get updates and bug fixes to the CRT via windows updates, but still allow your application to work on older machines without the newer dlls, by using the ones you provided. Clint - Original Message - Yes, I think part of the issue is what is mentioned and I do have plugins (Qt based) and have taken the steps he lays out. But I am still curious as to why Dependency Walker says it is using one version of the runtime libraries when the Manifest (both external and embedded) says to use another. I am probably just missing something basic in all of this. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Aug 9, 2011, at 3:07 PM, Michael Wild wrote: On Tue 09 Aug 2011 06:48:34 PM CEST, Michael Jackson wrote: Not sure if this is a CMake issue or not but I'll give it a shot. I am packaging up my application using CPack (zip) and all seems fine. I get the MSVC runtime libraries copied and the manifest file created and all seems to run just fine. If I use Dependency Walker to look at exactly _which_ C/C++ runtime DLLs are being loaded it seems to indicate a newer version than what the manifest is saying. My Application seems to be requesting version 9.0.21022.8 in its manifest and in the executable itself (Embedded Manifest) but Dependency Walker says it is really loading the 9.0.30729.490 version from the winsxs folder. I am still really new to this with Visual Studio so I am not sure if I am doing something incorrect when writing the CPack code, something in Visual Studio, how I compiled all the dependent libraries or what but any help or pushes in a better direction would be greatly appreciated. System: Windows 7 X64 Pro. Visual Studio 2008. Compiling everything as 64 bit. The actual executables can be downloaded from http://dream3d.bluequartz.net. Thanks in advance. Not sure, but could it be the issue mentioned in Bills blog? http://www.kitware.com/blog/home/post/4 Michael ___ 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 Thanks for this pointer, Clinton. I'll add a comment to Bill's blog article that also points to this Microsoft page... Good reference. :-) 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] Not matching versions of MSVC Runtime Libraries in Manifest
On Aug 9, 2011, at 3:30 PM, David Partyka wrote: Very cool! +1 On Tue, Aug 9, 2011 at 3:28 PM, David Cole david.c...@kitware.com wrote: On Tue, Aug 9, 2011 at 3:27 PM, clin...@elemtech.com wrote: Here's my (not so complete) understanding... Public assemblies are searched before private ones. http://msdn.microsoft.com/en-us/library/aa374224(v=vs.85).aspx So, on your machine, you have the required CRT libraires in the winsxs folder. You also have a redirection that says to use a newer CRT library if a particular older one is requested. If another machine that you copy this software to doesn't have a shared CRT that will work, it falls back to the one you copied next to your application. So its a way to get updates and bug fixes to the CRT via windows updates, but still allow your application to work on older machines without the newer dlls, by using the ones you provided. Clint - Original Message - Yes, I think part of the issue is what is mentioned and I do have plugins (Qt based) and have taken the steps he lays out. But I am still curious as to why Dependency Walker says it is using one version of the runtime libraries when the Manifest (both external and embedded) says to use another. I am probably just missing something basic in all of this. ___ Mike Jackson www.bluequartz.net On Aug 9, 2011, at 3:07 PM, Michael Wild wrote: On Tue 09 Aug 2011 06:48:34 PM CEST, Michael Jackson wrote: Not sure if this is a CMake issue or not but I'll give it a shot. I am packaging up my application using CPack (zip) and all seems fine. I get the MSVC runtime libraries copied and the manifest file created and all seems to run just fine. If I use Dependency Walker to look at exactly _which_ C/C++ runtime DLLs are being loaded it seems to indicate a newer version than what the manifest is saying. My Application seems to be requesting version 9.0.21022.8 in its manifest and in the executable itself (Embedded Manifest) but Dependency Walker says it is really loading the 9.0.30729.490 version from the winsxs folder. I am still really new to this with Visual Studio so I am not sure if I am doing something incorrect when writing the CPack code, something in Visual Studio, how I compiled all the dependent libraries or what but any help or pushes in a better direction would be greatly appreciated. System: Windows 7 X64 Pro. Visual Studio 2008. Compiling everything as 64 bit. The actual executables can be downloaded from http://dream3d.bluequartz.net. Thanks in advance. Not sure, but could it be the issue mentioned in Bills blog? http://www.kitware.com/blog/home/post/4 Michael Thanks for this pointer, Clinton. I'll add a comment to Bill's blog article that also points to this Microsoft page... Good reference. :-) David Thanks for all the explanations and web links. I think I have a better understanding of what is going on and how things are getting loaded. I'll talk to my customer about some more testing to make sure the changes I made corrected the loading bug. -- 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
Re: [CMake] access absolute path of parent directory
Sure.
Here is what I have(I've tried it with double quotes as well):
set(Bob /..)
set(Dave ${Bob}/Dave)
set(D_src ${Dave/Dave.cpp)
... and corresponding add executable command at which point the following
error is produced:
CMake Error at CMakeLists.txt:100 (add_executable):
Cannot find source file:
/../Dave/Dave.cpp
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
Let me know if you would need more information.
Thanks for your help,
Vinay
On Tue, Aug 9, 2011 at 12:30 PM, John Drescher dresche...@gmail.com wrote:
I've been trying to access the parent directory by using
CMakeLists.txt. However, the ../ or .. or /../ notations don't
access
said parent directory.
Can you show a small example? I know this has worked for me.
John
___
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] Fwd: access absolute path of parent directory
-- Forwarded message --
From: John Drescher dresche...@gmail.com
Date: Tue, Aug 9, 2011 at 4:56 PM
Subject: Re: [CMake] access absolute path of parent directory
To: Vinay Raj Hampapur vinayraj.hampa...@gmail.com
On Tue, Aug 9, 2011 at 4:24 PM, Vinay Raj Hampapur
vinayraj.hampa...@gmail.com wrote:
Sure.
Here is what I have(I've tried it with double quotes as well):
set(Bob /..)
set(Dave ${Bob}/Dave)
set(D_src ${Dave/Dave.cpp)
... and corresponding add executable command at which point the following
error is produced:
You are setting Bob to be the root folder of your system. Remove the /
in your first set
set(Bob ..)
John
--
John M. Drescher
___
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] Weird behaviour with CPackComponent and NSIS
I've recently upgraded to CMake 2.8.5 to try out the new CPack/CPackComponent separation, which allows me to include CPackComponent to get the various cpack component macros, but only include CPack later. I end up with very strange things happening, which I haven't been able to debug. What I did, is that instead of including CPack at the beginning of my project, I included CPackComponent instead, and included CPack at the end. I want to be able to do this so that I can use CPACK_NSIS_EXTRA_INSTALL_COMMANDS, among others. For some unknown reason, some of my components end up flagged as downloadable, and when I run cpack it then fails because I don't have the NSIS plugin to support this. If I unset the CPACK_COMPONENT_MYCOMPONENT_DOWNLOADABLE, then it doesn't happen, but the files from that component do not get installed. This is especially strange because it only affects some components but not others. I have a fairly complicated CMake project with a lot of add_subdirectory and recursive functions that include files, so I wonder if it doesn't get confused by the scoping somehow. Are there any known problems with the new CPackComponent approach? ___ 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] Fwd: access absolute path of parent directory
Thanks, John. I'm pretty sure I tried that earlier and it failed. It's
working now!
Cheers,
Vinay
On Tue, Aug 9, 2011 at 1:57 PM, John Drescher dresche...@gmail.com wrote:
-- Forwarded message --
From: John Drescher dresche...@gmail.com
Date: Tue, Aug 9, 2011 at 4:56 PM
Subject: Re: [CMake] access absolute path of parent directory
To: Vinay Raj Hampapur vinayraj.hampa...@gmail.com
On Tue, Aug 9, 2011 at 4:24 PM, Vinay Raj Hampapur
vinayraj.hampa...@gmail.com wrote:
Sure.
Here is what I have(I've tried it with double quotes as well):
set(Bob /..)
set(Dave ${Bob}/Dave)
set(D_src ${Dave/Dave.cpp)
... and corresponding add executable command at which point the following
error is produced:
You are setting Bob to be the root folder of your system. Remove the /
in your first set
set(Bob ..)
John
--
John M. Drescher
___
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] exclude build project from solution
Dave, Bill? Anyone know what the difference is intended to be between
EXLUDE_FROM_ALL vs EXCLUDE_FROM_DEFAULT_BUILD?
/Johan
On Mon, Aug 1, 2011 at 6:57 PM, Johan Björk p...@spotify.com wrote:
And another update while at it.
The following cmake file illustrates the issue:
FILE(WRITE foo.c )
add_library(foo EXCLUDE_FROM_ALL foo.c)
set_target_properties(foo PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD 1)
FILE(WRITE foobar.c )
add_executable(foobar foobar.c)
target_link_libraries(foobar foo)
This works fine in the makefile (and xcode) generator, but fails in MSVC
2008 with
1-- Skipped Build: Project: foo, Configuration: Debug Win32 --
1Project not selected to build for this solution configuration
2-- Build started: Project: foobar, Configuration: Debug Win32 --
2Compiling...
2foobar.c
2Compiling manifest to resources...
2Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0
2Copyright (C) Microsoft Corporation. All rights reserved.
2Linking...
2LINK : fatal error LNK1104: cannot open file 'Debug\foo.lib'
2Build log was saved at file://c:\Users\Felix Bruns\Documents\Visual
Studio 2008\Projects\a'\foobar.dir\Debug\BuildLog.htm
2foobar - 1 error(s), 0 warning(s)
3-- Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32
--
3Project not selected to build for this solution configuration
== Build: 0 succeeded, 1 failed, 1 up-to-date, 2 skipped ==
I'll file a bug.
On Mon, Aug 1, 2011 at 5:15 PM, Johan Björk p...@spotify.com wrote:
and I just found
The EXCLUDE_FROM_DEFAULT_BUILD property is used by the visual studio
generators. If it is set to 1 the target will not be part of the default
build when you select Build Solution.
Anyone know why it is different from EXLUDE_FROM_ALL ?
-Johan
On Mon, Aug 1, 2011 at 5:05 PM, Johan Björk p...@spotify.com wrote:
Hi all,
Anyone know anything about this? I'm seeing the same issue with MSVC 2008
+ cmake 2.8(.?)
add_library(foo .. EXCLUDE_FROM_ALL ..)
-Johan
On Tue, May 3, 2011 at 4:59 PM, Andrea Galeazzi galea...@korg.itwrote:
I've a project made up of multiple executable target:
add_executable(TARGET_NAME1 ${SOURCES1})
add_executable(TARGET_NAME2 ${SOURCES2})
add_executable(TARGET_NAME3 ${SOURCES3})
...
Now I'd like to build just only TARGET_NAME1 when I press F7 (build
solution) in visual studio. I tried to add
set_target_properties(TARGET_**NAME2 PROPERTIES EXCLUDE_FROM_ALL
TRUE)
set_target_properties(TARGET_**NAME3 PROPERTIES EXCLUDE_FROM_ALL
TRUE)
..
but it only remove the dependency from ALL_BUILD project.
So, is it possible to generate a such kind of solution?
__**_
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/**listinfo/cmakehttp://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
[CMake] Cross compiling and linking
I'm trying to compile code for an ARM processor on an x86-64 Ubuntu machine. I'm using scratchbox, compiling programes with the standard autoconf/configure scripts work fine so the cross compiler works. When I use Cmake I runinto problems, the following is my arm_cross.cmake file INCLUDE(CMakeForceCompiler) SET(CMAKE_SYSTEM_NAME Linux) SET(CMAKE_SYSTEM_VERSION 1) CMAKE_FORCE_C_COMPILER(gcc GNU) CMAKE_FORCE_CXX_COMPILER(g++ GNU) SET(CMAKE_AR /scratchbox/compilers/arm-linux-cs2010q1-202/bin/sbox-arm-none-linux-gnueabi-ar) SET(CMAKE_LD /usr/bin/ld) SET(CMAKE_C_LINK_EXECUTABLE /scratchbox/compilers/bin/gcc FLAGS CMAKE_C_LINK_FLAGS LINK_FLAGS OBJECTS -o TARGET LINK_LIBRARIES) I have put together a quick test program with the following CMakeLists.txt add_executable (test test.c) All is good when I run cmake -DCMAKE_TOOLCHAIN_FILE=../arm_cross.cmake . then on running make I get Scanning dependencies of target test [100%] Building C object CMakeFiles/test.dir/test.c.o Linking C executable test /scratchbox/compilers/arm-linux-cs2010q1-202/bin/sbox-arm-none-linux-gnueabi-gcc: No such file or directory make[2]: *** [test] Error 1 make[1]: *** [CMakeFiles/test.dir/all] Error 2 make: *** [all] Error 2 I have tried it with and without the last line in the target file and the result is the same. If I force it to use the ARM version of gcc for linking by setting SET(CMAKE_C_LINK_EXECUTABLE /usr/bin/gcc FLAGS CMAKE_C_LINK_FLAGS LINK_FLAGS OBJECTS -o TARGET LINK_LIBRARIES) then it fails on a call to ld, which it guesses correctly but complians with the following output Linking C executable test sb_gcc_wrapper (/scratchbox/compilers/bin/ld): /scratchbox/compilers/arm-linux-cs2010q1-202/bin/sbox-arm-none-linux-gnueabi-ld: No such file or directory collect2: ld returned 1 exit status make[2]: *** [test] Error 1 make[1]: *** [CMakeFiles/test.dir/all] Error 2 make: *** [all] Error 2 Why is it that it doesn't like using the cross compiler for linking? How do I get this to work? TIA Christian ___ 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-commits] CMake branch, next, updated. v2.8.5-1456-g50f5fa3
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 50f5fa3d71b2e8eed53e3a663189f995427c2dcd (commit)
via c9761de7ad853c62aa2d7e0bc0a28bc697586d23 (commit)
via 208bb9009bda2b41747c34e536f561df8a59 (commit)
from 83c00cdf9677682ab4761bfb6c00ef5497217e18 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50f5fa3d71b2e8eed53e3a663189f995427c2dcd
commit 50f5fa3d71b2e8eed53e3a663189f995427c2dcd
Merge: 83c00cd c9761de
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 9 08:07:00 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 9 08:07:00 2011 -0400
Merge topic 'WriteConfigVersionFile_2TemplateFiles' into next
c9761de Improve documentation for WriteBasicConfigVersionFile.cmake
208bb90 Set UNSUITABLE instead of not COMPATIBLE
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9761de7ad853c62aa2d7e0bc0a28bc697586d23
commit c9761de7ad853c62aa2d7e0bc0a28bc697586d23
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Aug 5 23:01:07 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Fri Aug 5 23:01:07 2011 +0200
Improve documentation for WriteBasicConfigVersionFile.cmake
Alex
diff --git a/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
b/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
index 469bcdb..cf53db8 100644
--- a/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
+++ b/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
@@ -1,5 +1,4 @@
-# This is a basic file for the new style find_package() search mode,
-# i.e. Config-mode.
+# This is a basic version file for the Config-mode of find_package().
# It is used by WriteBasicConfigVersionFile.cmake as input file for
configure_file()
# to create a version-file which can be installed along a config.cmake file.
#
diff --git a/Modules/BasicConfigVersion-SameMajorVersion.cmake.in
b/Modules/BasicConfigVersion-SameMajorVersion.cmake.in
index 8d091ea..2317fdb 100644
--- a/Modules/BasicConfigVersion-SameMajorVersion.cmake.in
+++ b/Modules/BasicConfigVersion-SameMajorVersion.cmake.in
@@ -1,5 +1,4 @@
-# This is a basic file for the new style find_package() search mode,
-# i.e. Config-mode.
+# This is a basic version file for the Config-mode of find_package().
# It is used by WriteBasicConfigVersionFile.cmake as input file for
configure_file()
# to create a version-file which can be installed along a config.cmake file.
#
diff --git a/Modules/WriteBasicConfigVersionFile.cmake
b/Modules/WriteBasicConfigVersionFile.cmake
index f0ad6ea..0b6519d 100644
--- a/Modules/WriteBasicConfigVersionFile.cmake
+++ b/Modules/WriteBasicConfigVersionFile.cmake
@@ -5,23 +5,27 @@
#filename is the output filename, it should be in the build tree.
#major.minor.patch is the version number of the project to be installed
# The COMPATIBILITY mode AnyNewerVersion means that the installed package
version
-# will be considered suitable if it is newer or exactly the same as the
requested version.
+# will be considered compatible if it is newer or exactly the same as the
requested version.
# If SameMajorVersion is used instead, then the behaviour differs from
AnyNewerVersion
# in that the major version number must be the same as requested, e.g. version
2.0 will
-# not be considered suitable to 1.0 is requested.
-# If you project has more elaborated version matching rules, you will need to
write your
-# own custom ConfigVersion.cmake file, instead of using this macro.
+# not be considered compatible if 1.0 is requested.
+# If your project has more elaborated version matching rules, you will need to
write your
+# own custom ConfigVersion.cmake file instead of using this macro.
#
# Example:
#
write_basic_config_version_file(${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
# VERSION 1.2.3
# COMPATIBILITY SameMajorVersion )
# install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
+# ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
# DESTINATION lib/cmake/Foo )
#
-# Internally, this macro executes configure_file() on the input file
-# Modules/BasicConfigVersion-AnyNewerVersion/SameMajorVersion.cmake.in to
-# create the resulting version file.
+# Internally, this macro executes configure_file() to create the resulting
+# version file. Depending on the COMPATIBLITY, either the file
+# BasicConfigVersion-SameMajorVersion.cmake.in or
BasicConfigVersion-AnyNewerVersion.cmake.in
+# is used. Please note that these two files are internal to
[Cmake-commits] CMake branch, next, updated. v2.8.5-1458-g9caca24
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9caca24903c0aa32174f50a23f78da231c1f1722 (commit)
via 706ed2b1b0376c8f6bce064315d83b564931d811 (commit)
from 50f5fa3d71b2e8eed53e3a663189f995427c2dcd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9caca24903c0aa32174f50a23f78da231c1f1722
commit 9caca24903c0aa32174f50a23f78da231c1f1722
Merge: 50f5fa3 706ed2b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 9 09:26:53 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 9 09:26:53 2011 -0400
Merge topic 'generate_export_header' into next
706ed2b Add a newline at the end of the file.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=706ed2b1b0376c8f6bce064315d83b564931d811
commit 706ed2b1b0376c8f6bce064315d83b564931d811
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 9 00:18:00 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Aug 9 15:02:48 2011 +0200
Add a newline at the end of the file.
Hopefully fix the test execution reported on CDash.
diff --git a/Tests/Module/GenerateExportHeader/libstatic/libstatic.cpp
b/Tests/Module/GenerateExportHeader/libstatic/libstatic.cpp
index c8b7d44..0710c3e 100644
--- a/Tests/Module/GenerateExportHeader/libstatic/libstatic.cpp
+++ b/Tests/Module/GenerateExportHeader/libstatic/libstatic.cpp
@@ -84,4 +84,4 @@ int libstatic_not_exported() {
int libstatic_excluded() {
return 0;
-}
\ No newline at end of file
+}
---
Summary of changes:
.../GenerateExportHeader/libstatic/libstatic.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.5-1460-g1d23a3b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 1d23a3b8b0975f78635387fe06445d6defc7f47e (commit) via b19911ecab8178230ef5f1605e7730f842b39633 (commit) from 9caca24903c0aa32174f50a23f78da231c1f1722 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d23a3b8b0975f78635387fe06445d6defc7f47e commit 1d23a3b8b0975f78635387fe06445d6defc7f47e Merge: 9caca24 b19911e Author: Stephen Kelly steve...@gmail.com AuthorDate: Tue Aug 9 13:04:24 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Aug 9 13:04:24 2011 -0400 Merge topic 'generate_export_header' into next b19911e Add missing licence header. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b19911ecab8178230ef5f1605e7730f842b39633 commit b19911ecab8178230ef5f1605e7730f842b39633 Author: Stephen Kelly steve...@gmail.com AuthorDate: Tue Aug 9 19:03:16 2011 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Tue Aug 9 19:03:45 2011 +0200 Add missing licence header. diff --git a/Modules/GenerateExportHeader.cmake b/Modules/GenerateExportHeader.cmake index 3665817..67a16a9 100644 --- a/Modules/GenerateExportHeader.cmake +++ b/Modules/GenerateExportHeader.cmake @@ -98,6 +98,20 @@ # # This will cause the export macros to expand to nothing when building the static library. + +#= +# Copyright 2011 Stephen Kelly steve...@gmail.com +# +# Distributed under the OSI-approved BSD License (the License); +# see accompanying file Copyright.txt for details. +# +# This software is distributed WITHOUT ANY WARRANTY; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +# See the License for more information. +#= +# (To distribute this file outside of CMake, substitute the full +# License text for the above reference.) + include(CMakeParseArguments) include(CheckCXXCompilerFlag) --- Summary of changes: Modules/GenerateExportHeader.cmake | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.5-1463-g931f9c1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 931f9c1e65fc52c888c928c2a98a032690fed2a2 (commit)
via 0167ceaf98c78f40532fc187b35440d033ac837e (commit)
via 4675f5d20423cd3331570a75794468bb3af1edaf (commit)
from 1d23a3b8b0975f78635387fe06445d6defc7f47e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=931f9c1e65fc52c888c928c2a98a032690fed2a2
commit 931f9c1e65fc52c888c928c2a98a032690fed2a2
Merge: 1d23a3b 0167cea
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 9 15:18:01 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 9 15:18:01 2011 -0400
Merge topic 'fix-12323-more-paths-in-finddcmtk' into next
0167cea Add more find_path locations for DCMTK header files (#12323)
4675f5d KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0167ceaf98c78f40532fc187b35440d033ac837e
commit 0167ceaf98c78f40532fc187b35440d033ac837e
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 9 15:13:46 2011 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Tue Aug 9 15:15:53 2011 -0400
Add more find_path locations for DCMTK header files (#12323)
diff --git a/Modules/FindDCMTK.cmake b/Modules/FindDCMTK.cmake
index 0ac22f8..361d09e 100644
--- a/Modules/FindDCMTK.cmake
+++ b/Modules/FindDCMTK.cmake
@@ -108,8 +108,10 @@ foreach(dir
PATHS
${DCMTK_DIR}/${dir}/include
${DCMTK_DIR}/${dir}
-${DCMTK_DIR}/include/${dir})
-
+${DCMTK_DIR}/include/${dir}
+${DCMTK_DIR}/include/dcmtk/${dir}
+${DCMTK_DIR}/${dir}/include/dcmtk/${dir}
+)
mark_as_advanced(DCMTK_${dir}_INCLUDE_DIR)
if(DCMTK_${dir}_INCLUDE_DIR)
---
Summary of changes:
Modules/FindDCMTK.cmake |6 --
Source/kwsys/kwsysDateStamp.cmake |2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.5-146-gc04613a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via c04613a55de394e17dab5972c540a3577d5a0f43 (commit)
from 4675f5d20423cd3331570a75794468bb3af1edaf (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c04613a55de394e17dab5972c540a3577d5a0f43
commit c04613a55de394e17dab5972c540a3577d5a0f43
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Aug 9 18:03:09 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Aug 9 18:04:04 2011 -0400
KWSys: __int64 and long long may be same type in specialization
For the specialization of hash(), the types long long and __int64
may be the same type. While the CMakeLists indicate that if __int64 is
a alias for another type the it will not be enabled, on mingw they
both appear to be the same type and enabled.
This patch only enable specialization for long long OR __int64 to
avoid the potential conflict.
Author: Bradley Lowekamp blowek...@mail.nih.gov
Change-Id: I813a9ac008b296fab5a369c48e6dd5460fd0c035
diff --git a/Source/kwsys/hash_fun.hxx.in b/Source/kwsys/hash_fun.hxx.in
index 9a9cf47..926ec92 100644
--- a/Source/kwsys/hash_fun.hxx.in
+++ b/Source/kwsys/hash_fun.hxx.in
@@ -110,6 +110,7 @@ struct hashunsigned long {
size_t operator()(unsigned long __x) const { return __x; }
};
+// use long long or __int64
#if @KWSYS_NAMESPACE@_USE_LONG_LONG
@KWSYS_NAMESPACE@_CXX_DEFINE_SPECIALIZATION
struct hashlong long {
@@ -120,9 +121,7 @@ struct hashlong long {
struct hashunsigned long long {
size_t operator()(unsigned long long __x) const { return __x; }
};
-#endif
-
-#if @KWSYS_NAMESPACE@_USE___INT64
+#elif @KWSYS_NAMESPACE@_USE___INT64
@KWSYS_NAMESPACE@_CXX_DEFINE_SPECIALIZATION
struct hash__int64 {
size_t operator()(__int64 __x) const { return __x; }
@@ -131,7 +130,7 @@ struct hash__int64 {
struct hashunsigned __int64 {
size_t operator()(unsigned __int64 __x) const { return __x; }
};
-#endif
+#endif // use long long or __int64
} // namespace @KWSYS_NAMESPACE@
---
Summary of changes:
Source/kwsys/hash_fun.hxx.in |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
