Re: [CMake] compiler defines for sub projects
You can make a variable contain the defines you want and the use that variable
in the set_target_properties command. The value of the variable will be
inherited by all of the sup directories.
option(FOO_OPTION enable foo OFF)
option(BAR_OPTION enable bar OFF)
if(FOO_OPTION)
set(CUSTOM_DEFINE FOO_X)
elseif(BAR_OPTION)
set(CUSTOM_DEFINE FOO_Y)
else
set(CUSTOM_DEFINE OTHER)
endif()
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS ${CUSTOM_DEFINE} )
On Apr 6, 2013, at 1:21 AM, Olaf Peter ope-de...@gmx.de wrote:
thanks for your answer.
I've forgot to mention in the hurry yesterday, that inisde the lib
project generator exist which must not compiled with these defines.
if(FOO_OPTION OR BAR_OPTION)
add_executable(generator_target ...)
set_target_properties(generator_target ... COMPILE_DEFINITIONS ...)
endif()
This is the reason for set_target_properties(my_lib ...)
So this solution with add_definitions won't work. Possible it could work
if I removed those defs from target.
Thanks,
Olaf
If you want to have all of the sub directories to have the defines
present, you could use ADD_DEFINITIONS().
option(FOO_OPTION enable foo OFF)
option(BAR_OPTION enable bar OFF)
if(FOO_OPTION)
add_definitions(-DFOO_X )
elseif(BAR_OPTION)
add_definitions(-DFOO_Y)
else()
add_definitions(-DOTHER)
endif()
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Olaf Peter
Sent: Friday, April 05, 2013 12:58 PM
To: cmake@cmake.org
Subject: [CMake] compiler defines for sub projects
Hello,
is it possible to inherit compiler defines for sub projects in sub
directories?
I have a library project which can be configured at compile time
using preprocessor defines (cmake option)
option(FOO_OPTION enable foo OFF)
option(BAR_OPTION enable bar OFF)
if(FOO_OPTION)
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS
FOO_X )
elseif(BAR_OPTION)
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS
FOO_Y)
else()
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS
OTHER )
endif()
now, in the sub of this I have unit tests which need to know about
this compile defs, hence I have the same if/else again.
Is there an easy way for this?
Thanks,
Olaf
--
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] compiler defines for sub projects
If you want to have all of the sub directories to have the defines present, you could use ADD_DEFINITIONS(). option(FOO_OPTION enable foo OFF) option(BAR_OPTION enable bar OFF) if(FOO_OPTION) add_definitions(-DFOO_X ) elseif(BAR_OPTION) add_definitions(-DFOO_Y) else() add_definitions(-DOTHER) endif() -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Olaf Peter Sent: Friday, April 05, 2013 12:58 PM To: cmake@cmake.org Subject: [CMake] compiler defines for sub projects Hello, is it possible to inherit compiler defines for sub projects in sub directories? I have a library project which can be configured at compile time using preprocessor defines (cmake option) option(FOO_OPTION enable foo OFF) option(BAR_OPTION enable bar OFF) if(FOO_OPTION) set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS FOO_X ) elseif(BAR_OPTION) set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS FOO_Y) else() set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS OTHER ) endif() now, in the sub of this I have unit tests which need to know about this compile defs, hence I have the same if/else again. Is there an easy way for this? Thanks, Olaf -- 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] how to compile as 32bit on a 64bit Linux host ?
What I have done in the past is the -m32 flag to the CMAKE_CXX_FLAGS and all of the search paths were updated automatically. You just need to add the flag when you CMake for the first time. I did this on CentOS 5.8 x64 without any problems. Keith -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Yngve Inntjore Levinsen Sent: Friday, February 15, 2013 9:27 AM To: cmake@cmake.org Subject: Re: [CMake] how to compile as 32bit on a 64bit Linux host ? Hello, On 15/02/13 15:41, Martin Koller wrote: I'm just not sure if it is enough to change the compiler flags or if there is more to change (paths etc.) This is why I prefer toolchain files over adding an option inside the CMakeLists.txt files. On some systems you probably also want to change the search path for libraries in particular (often /usr/lib32 instead of /usr/lib), so that the find_package() commands and similar does not find the incompatible 64 bit libraries. In our system we both have an option to force 32 bit (which basically just adds -m32 to compile flags), and I have a toolchain file (which corresponds to my stackoverflow answer). I find the toolchain file to be more accurate/flexible to get correct setup. In addition to the three lines you might also want to set paths (I do not need that on my system for my projects), something along the lines of: set(CMAKE_FIND_ROOT_PATH /usr/lib32) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) Cheers, Yngve -- 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] Find a library that matches a specific pattern
You can use file(GLOB variable [RELATIVE path] [globbing expression] ...)
file( GLOB result ${first_build_dir} filea*.lib)
Result will contain a list of files that match the globbing expression.
Enjoy!
Keith
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
katie outram
Sent: Wednesday, November 28, 2012 2:37 PM
To: cmake@cmake.org
Subject: [CMake] Find a library that matches a specific pattern
I have a build that depends on the output from another build. We can't
combine the code into one build due to other issues.
I need to get cmake to pass the values of the libraries I want to link against.
I have worked out a find script for my second build that allows me to use
the find_library command to pull the .lib file that I'm looking for.
However, I must force the user to specify the specific name of the library and
I need to avoid this and just be able to pick up the value if the name passes
validation and the version is any number since ultimately this whole process
will be automated and I don't want to have to worry about specifying version
numbers.
My first build creates a directory
* build
* win64
* VC10
* bin
* Release
* filea1231.1.1.1.lib
* fileb2341.1.1.1.lib
* filec3451.1.1.1.lib
For the second build I force the user to tell me the path of the build
directory (i.e. C:\build\win64\VC10\bin\Release and assign this to a value of
first_build_dir)
I then have a find script where I am trying to find the library (i.e.
filea1231.1.1.1)
set (file_name filea1231.1.1.1)
find_library(my_library
name ${file_name}
PATHS ${first_build_dir}
)
The problem I have is that the filea1231.1.1.1 might change for the next build
(i.e filea1231.1.1.2).There is only one file named filea so I'd like to be
able to search for filea*.lib no matter what the versioning information
contains.
I thought I needed to go down the path of using a string(regex
match([filea0-9]+\\.[0-9]\\.[0-9]\\.[0-9file:///\\.[0-9]\.%5b0-9] file_name)
however I can't figure out how to make this work in my current situation.
I then went down the path of trying the file(strings filea*.lib file_name)
option but it returned my ${first_build_dir} path
I'm looking for suggestions on how to handle pulling the changing file name
within cmake for use at anytime.
Thanks
--
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-gui's separation between configuration generation
Hi, Even if the Linux environment does not have a GUI, you can use ccmake. It is like the cmake-gui but runs inside a terminal window. I use this all the time on Windows through putty. As for clicking generate, with the latest version of CMake, you can click generate without clicking configure and you have the behavior of cmake CLI. At my company, we have many CMake options and need to configure multiple times, even on Linux. -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Andreas Pakulat Sent: Thursday, August 23, 2012 1:32 PM To: Robert Dailey Cc: CMake ML Subject: Re: [CMake] cmake-gui's separation between configuration generation Hi, On Thu, Aug 23, 2012 at 8:20 PM, Robert Dailey rcdailey.li...@gmail.com wrote: On Thu, Aug 23, 2012 at 1:12 PM, Andreas Pakulat ap...@gmx.de wrote: Hi, On Thu, Aug 23, 2012 at 5:48 PM, Robert Dailey rcdailey.li...@gmail.com wrote: On Thu, Aug 23, 2012 at 10:43 AM, John Drescher dresche...@gmail.com wrote: Is the separation between configuration generation really necessary for cmake-gui? I ask because several of my co-workers are confused between the differences in the two, even though I explain it. Honestly there isn't really a reason that I can think of to do a configure without a generate, unless you're testing the integrity of your CMake script changes maybe, but even then, if its broken generation won't take place. The command line program does not separate the two, so I simply think cmake-gui should eliminate the configure button, and simply have a generate button. Does this seem fair? Is there a reason why they are separated? I can think of one use case that I use that the separation is a good thing. What about when you have options and variables that are conditional depending on other CMake variables so that setting the variables / options may take more than 1 configure. Well, think of this from the perspective of Linux users. They don't get to configure seperately, so only Windows users get special treatment here (and maybe Mac too, since it's using Qt). You need to check your facts a bit more thoroughly ;) cmake-gui exists on all platforms that Qt exists on, specifically because Qt is cross-platform. And Qt runs on Windows, Linux, MacOSX and a few more Unices. I already knew all of this, what I was saying is that not everyone has Linux with a GUI, so they'd HAVE to use the CLI for CMake in that case. I'm only on Windows anyway, so my example is limited to that. I think the majority of Linux users these days have a graphical display at hand, just like MacOSX or Windows users. The cases where CMake is run from the commandline is IMO the same on all platforms: Either because the users like CLI better or because the machine indeed has no display since its not needing one (read: Buildfarms). Andreas -- 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] Clang + MinGW Linking Issue
Never mind. I just tried it again and it looks like Visual Studio was using
its own compiler even though I specified a different one with CMake. I tried
it with NMake and I could tell that it was using clang but I couldn't get past
include errors with the ammintrin.h header.
From: Justin Holewinski [mailto:justin.holewin...@gmail.com]
Sent: Thursday, May 24, 2012 5:28 PM
To: Keith Gardner
Cc: Brad King; cmake@cmake.org
Subject: Re: [CMake] Clang + MinGW Linking Issue
Were you passing custom command-line arguments in the project? Clang only
accepts a very limited set of CL-style arguments (AFAIK):
c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe
c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe -Zm
clang: error: unsupported use of internal gcc -Z option '-Zm'
c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe -MT
clang: error: argument to '-MT' is missing (expected 1 value)
This is with a Clang built with the compilers from the Windows SDK 7.1.
On Thu, May 24, 2012 at 2:12 PM, Keith Gardner
kgard...@zebraimaging.commailto:kgard...@zebraimaging.com wrote:
I have built clang (llvm) on windows with Visual Studio 2010 and used the built
binaries as the compiler inside of a Visual Studio project. This was with
clang 3.0 and llvm 2.9.1.
From: cmake-boun...@cmake.orgmailto:cmake-boun...@cmake.org
[mailto:cmake-boun...@cmake.orgmailto:cmake-boun...@cmake.org] On Behalf Of
Justin Holewinski
Sent: Thursday, May 24, 2012 1:49 PM
To: Brad King
Cc: cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] Clang + MinGW Linking Issue
On Thu, May 24, 2012 at 10:08 AM, Brad King
brad.k...@kitware.commailto:brad.k...@kitware.com wrote:
On 05/24/2012 12:22 PM, Justin Holewinski wrote:
I narrowed the problem down to Clang not having
Platform/Windows-Clang-{C,CXX}.cmake files.
There is an issue tracker entry for this:
http://www.cmake.org/Bug/view.php?id=13035
but it is in the backlog waiting for more feedback and a volunteer.
The main problem is distinguishing the GNU-compatible and MS-compatible
builds of Clang.
Oops, missed that issue. Sorry about that!
If I add the following two files then everything starts to work as expected:
Platform/Windows-Clang-C.cmake:
if(MINGW)
include(Platform/Windows-GNU)
__windows_compiler_gnu(C)
else()
# Chain to generic Windows configuration
include(Platform/Windows)
endif()
Platform/Windows-Clang-CXX.cmake:
if(MINGW)
include(Platform/Windows-GNU)
__windows_compiler_gnu(C)
else()
# Chain to generic Windows configuration
include(Platform/Windows)
endif()
This way, using Clang with MinGW will force GNU-style platform
options instead of VS-style Windows options.
Is this more or less the right way to fix this in CMake?
Interesting approach. That may be better than separating the
compiler id as mentioned in the above-linked issue. The MINGW
value is set based on CMAKE_C_PLATFORM_ID which is computed in
the same way and at the same time as CMAKE_C_COMPILER_ID. Try:
$ cat Platform/Windows-Clang-C.cmake
if(${CMAKE_C_PLATFORM_ID} MATCHES MinGW)
include(Platform/Windows-GNU-C)
else()
include(Platform/Windows-cl)
endif()
$ cat Platform/Windows-Clang-CXX.cmake
if(${CMAKE_CXX_PLATFORM_ID} MATCHES MinGW)
include(Platform/Windows-GNU-CXX)
else()
include(Platform/Windows-cl)
endif()
Do you have both the MS-style and GNU-style Clang available
to test?
This works for the MinGW build. I really can't say if this fixes the library
naming issue for the MS-style Clang. Clang does not have a VC-compatible
driver (that I know of) so does not accept VC-style arguments like /O2, which
causes CMake to fail early on in the configure process when using the NMake
generator. Clang with MinGW is the only really supported configuration at this
point.
Thanks,
-Brad
--
Thanks,
Justin Holewinski
--
Thanks,
Justin Holewinski
--
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] Clang + MinGW Linking Issue
I have built clang (llvm) on windows with Visual Studio 2010 and used the built
binaries as the compiler inside of a Visual Studio project. This was with
clang 3.0 and llvm 2.9.1.
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Justin Holewinski
Sent: Thursday, May 24, 2012 1:49 PM
To: Brad King
Cc: cmake@cmake.org
Subject: Re: [CMake] Clang + MinGW Linking Issue
On Thu, May 24, 2012 at 10:08 AM, Brad King
brad.k...@kitware.commailto:brad.k...@kitware.com wrote:
On 05/24/2012 12:22 PM, Justin Holewinski wrote:
I narrowed the problem down to Clang not having
Platform/Windows-Clang-{C,CXX}.cmake files.
There is an issue tracker entry for this:
http://www.cmake.org/Bug/view.php?id=13035
but it is in the backlog waiting for more feedback and a volunteer.
The main problem is distinguishing the GNU-compatible and MS-compatible
builds of Clang.
Oops, missed that issue. Sorry about that!
If I add the following two files then everything starts to work as expected:
Platform/Windows-Clang-C.cmake:
if(MINGW)
include(Platform/Windows-GNU)
__windows_compiler_gnu(C)
else()
# Chain to generic Windows configuration
include(Platform/Windows)
endif()
Platform/Windows-Clang-CXX.cmake:
if(MINGW)
include(Platform/Windows-GNU)
__windows_compiler_gnu(C)
else()
# Chain to generic Windows configuration
include(Platform/Windows)
endif()
This way, using Clang with MinGW will force GNU-style platform
options instead of VS-style Windows options.
Is this more or less the right way to fix this in CMake?
Interesting approach. That may be better than separating the
compiler id as mentioned in the above-linked issue. The MINGW
value is set based on CMAKE_C_PLATFORM_ID which is computed in
the same way and at the same time as CMAKE_C_COMPILER_ID. Try:
$ cat Platform/Windows-Clang-C.cmake
if(${CMAKE_C_PLATFORM_ID} MATCHES MinGW)
include(Platform/Windows-GNU-C)
else()
include(Platform/Windows-cl)
endif()
$ cat Platform/Windows-Clang-CXX.cmake
if(${CMAKE_CXX_PLATFORM_ID} MATCHES MinGW)
include(Platform/Windows-GNU-CXX)
else()
include(Platform/Windows-cl)
endif()
Do you have both the MS-style and GNU-style Clang available
to test?
This works for the MinGW build. I really can't say if this fixes the library
naming issue for the MS-style Clang. Clang does not have a VC-compatible
driver (that I know of) so does not accept VC-style arguments like /O2, which
causes CMake to fail early on in the configure process when using the NMake
generator. Clang with MinGW is the only really supported configuration at this
point.
Thanks,
-Brad
--
Thanks,
Justin Holewinski
--
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] Android In-Depth CMake Questions
You could also look at the OpenCV project. They already support building for Android and are completely CMake based. -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Gregory Peele ARA/CFD Sent: Friday, March 16, 2012 2:03 PM To: cmake@cmake.org Subject: Re: [CMake] Android In-Depth CMake Questions -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Friday, March 16, 2012 2:39 PM To: cmake@cmake.org Subject: Re: [CMake] Android In-Depth CMake Questions Gregory Peele ARA/CFD wrote: Hi all, I'm experimenting with adding more in-depth support for Android to my CMake-based projects since I have a large body of CMake-built C++ code I want to use on Android (but not make Android-specific). I used the Google Android toolchain file as a starting point for NDK support, and wrote a platform definition for Android so that the toolchain file only has to locate the right cross compiler. I also wrote functions to define Android APK targets using the Android SDK and Ant (for now) to compile the Java pieces and the final APK, where my functions deal with generating temporary Android projects for each APK target, generating an Android manifest from a template file based on CMake variables, and staging native CMake .so targets and non-system external libraries into the right spot to be put into the APK. The APK install step also has an option to install to the Android emulator or attached devices using ADB. First off, is there any general interest in this kind of work? Would other people find this sort of thing useful in CMake itself? Absolutely. I know that some people in KDE are trying to get their stuff ported to Android as well. Since KDE is basically entirely CMake- based everything that CMake could do out of the box will likely be of great value to them. Eike Very cool, I didn't know that. That could also dovetail nicely with some of my long-term interests which involve porting my terrain visualization GUI applications (based on Qt and OpenSceneGraph, though not KDE). 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] Updated: CMake 2.8.7-1
Never mind, I manually installed 2.8.6. I uninstalled 2.8.6 and all is well. -Original Message- From: Keith Gardner Sent: Tuesday, March 06, 2012 11:43 AM To: 'Bill Hoffman'; cygwin-annou...@cygwin.com; cm...@public.kitware.com Subject: RE: [CMake] Updated: CMake 2.8.7-1 I just did an update of CMake on Cygwin and found a weird inconstancy. the Cygwin installer calls the version 2.8.7-1 but if you run cmake -version you get 2.8.6. Which is correct? -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent: Tuesday, March 06, 2012 7:54 AM To: cygwin-annou...@cygwin.com; cm...@public.kitware.com Subject: [CMake] Updated: CMake 2.8.7-1 CMake 2.8.7-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - improved Eclipse support - incremental improvements to the AUTOMOC feature added in the previous release - more cryptographic hash implementations (SHA1, SHA224, SHA256, SHA384, SHA512) - file(...) and string(...) command additions for computing hash values - added LINK_PUBLIC and LINK_PRIVATE options to target_link_libraries command - new module: DeployQt4 - and, as always, various minor bug fixes Similar to the previous release, we do not have pre-built binaries for the SunOS anymore. However, now we have two sets of installers for the Mac. The Darwin versions are for Mac OSX 10.4 and later, and are ppc;i386 universal binaries. The Darwin64 versions are for 10.6 and later, and are x86_64;i386 universal binaries. There was a bit of a network connectivity snag in building the binaries for the AIX platform today... Because of this, the tarballs for AIX will not be available until sometime next week. Following is the complete list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Thanks for using CMake! -Bill Changes in CMake 2.8.7 (since 2.8.7-rc2) None Changes in CMake 2.8.7-rc2 (since 2.8.7-rc1) Alex Neundorf (5): automoc: default to strict mode, use CMAKE_AUTOMOC_RELAXED_MODE automoc: improved warning message in relaxed mode Remove trailing whitespace Add comment about one more problem of the C depency scanner. fix #12262: dependency scanning for ASM files Bill Hoffman (1): Fix the case where cmake --build failed with two project cmds in one file. Brad King (11): KWSys: Correctly handle empty environment variables FortranCInterface: Work around mingw32-make trouble with parens Xcode: Create separate rerun dependencies for subprojects (#12616) Fix Intel Fortran .vfproj files for VS 10 HP: Drive shared library linking with compiler front end Follow all dependencies of shared library private dependencies Do not link private dependent shared libraries on OS X 10.4 Avoid clobbering variable 'OUTPUT' in compiler tests (#12628) Fix and simplify Fortran test compiler compatibility check CTest: Recognize Intel errors without space before colon (#12627) Windows-GNU: Remove extra quotes in GNUtoMS rule variable David Cole (4): Release: Increase timeout for slow-testing cygwin build Modules: Use windres as rc compiler base name for cross-compiles (#12480) Tests: Only really run MFC test if we can build MFC apps (#11213) FindBoost: Quote possibly empty string argument (#12273) Eric NOULARD (1): CPackRPM fix #0012608 and unoticed related bug Johan Fänge (1): CMake: Fix progress reporting for custom targets (#12441) Mike McQuaid (2): Unset configurations variable when no build type. Improve component support and output indentation. Raphael Kubo da Costa (2): Remove the apparently outdated README in Source/QtDialog. QtDialog: Set Ctrl+Q as the shortcut for quitting the program. Tim Gallagher (2): FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624) FindLAPACK: List thread libs to avoid link errors (#12625) Valat Sébastien (1): CTest: Do not get CDash version without drop site (#12618) Changes in CMake 2.8.7-rc1 (since 2.8.6) Aaron Ten Clay (1): VS: Add support for three new project properties (#12586) Alex Neundorf (60): fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects fix #12262: use the C dependency scanner also for ASM files fix #12465: detect the masm compiler ID (MSVC) Silence make on OpenBSD in FindPackageModeTest(#12508) Remove trailing whitespace Find Ruby on OpenBSD when installed from ports (#12507) Eclipse generator: detect Eclipse version Detect whether the current Eclipse version supports VirtualFolders Eclipse: don't create VirtualFolders
Re: [CMake] Updated: CMake 2.8.7-1
I just did an update of CMake on Cygwin and found a weird inconstancy. the Cygwin installer calls the version 2.8.7-1 but if you run cmake -version you get 2.8.6. Which is correct? -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent: Tuesday, March 06, 2012 7:54 AM To: cygwin-annou...@cygwin.com; cm...@public.kitware.com Subject: [CMake] Updated: CMake 2.8.7-1 CMake 2.8.7-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - improved Eclipse support - incremental improvements to the AUTOMOC feature added in the previous release - more cryptographic hash implementations (SHA1, SHA224, SHA256, SHA384, SHA512) - file(...) and string(...) command additions for computing hash values - added LINK_PUBLIC and LINK_PRIVATE options to target_link_libraries command - new module: DeployQt4 - and, as always, various minor bug fixes Similar to the previous release, we do not have pre-built binaries for the SunOS anymore. However, now we have two sets of installers for the Mac. The Darwin versions are for Mac OSX 10.4 and later, and are ppc;i386 universal binaries. The Darwin64 versions are for 10.6 and later, and are x86_64;i386 universal binaries. There was a bit of a network connectivity snag in building the binaries for the AIX platform today... Because of this, the tarballs for AIX will not be available until sometime next week. Following is the complete list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Thanks for using CMake! -Bill Changes in CMake 2.8.7 (since 2.8.7-rc2) None Changes in CMake 2.8.7-rc2 (since 2.8.7-rc1) Alex Neundorf (5): automoc: default to strict mode, use CMAKE_AUTOMOC_RELAXED_MODE automoc: improved warning message in relaxed mode Remove trailing whitespace Add comment about one more problem of the C depency scanner. fix #12262: dependency scanning for ASM files Bill Hoffman (1): Fix the case where cmake --build failed with two project cmds in one file. Brad King (11): KWSys: Correctly handle empty environment variables FortranCInterface: Work around mingw32-make trouble with parens Xcode: Create separate rerun dependencies for subprojects (#12616) Fix Intel Fortran .vfproj files for VS 10 HP: Drive shared library linking with compiler front end Follow all dependencies of shared library private dependencies Do not link private dependent shared libraries on OS X 10.4 Avoid clobbering variable 'OUTPUT' in compiler tests (#12628) Fix and simplify Fortran test compiler compatibility check CTest: Recognize Intel errors without space before colon (#12627) Windows-GNU: Remove extra quotes in GNUtoMS rule variable David Cole (4): Release: Increase timeout for slow-testing cygwin build Modules: Use windres as rc compiler base name for cross-compiles (#12480) Tests: Only really run MFC test if we can build MFC apps (#11213) FindBoost: Quote possibly empty string argument (#12273) Eric NOULARD (1): CPackRPM fix #0012608 and unoticed related bug Johan Fänge (1): CMake: Fix progress reporting for custom targets (#12441) Mike McQuaid (2): Unset configurations variable when no build type. Improve component support and output indentation. Raphael Kubo da Costa (2): Remove the apparently outdated README in Source/QtDialog. QtDialog: Set Ctrl+Q as the shortcut for quitting the program. Tim Gallagher (2): FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624) FindLAPACK: List thread libs to avoid link errors (#12625) Valat Sébastien (1): CTest: Do not get CDash version without drop site (#12618) Changes in CMake 2.8.7-rc1 (since 2.8.6) Aaron Ten Clay (1): VS: Add support for three new project properties (#12586) Alex Neundorf (60): fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects fix #12262: use the C dependency scanner also for ASM files fix #12465: detect the masm compiler ID (MSVC) Silence make on OpenBSD in FindPackageModeTest(#12508) Remove trailing whitespace Find Ruby on OpenBSD when installed from ports (#12507) Eclipse generator: detect Eclipse version Detect whether the current Eclipse version supports VirtualFolders Eclipse: don't create VirtualFolders if not supported Eclipse: better message when Eclipse version could not be determined automoc:run moc on the header if the source file contains include foo.moc Add copyright notices automoc: always run moc on the cpp file if there is a foo.moc included Eclipse:
Re: [CMake] Eliminate Debug/Release directories and name executables based on configuration
What you need to do to get rid of the Debug/Release directories is set the
prefix property for your target with ../.
Eg. set_target_properties( target_name PROPERTIES PREFIX ../ )
To get a postfix for different configuration types you need to set the postfix
property for the build type.
Eg. set_target_properties( target_name PROPERTIES DEBUG_POSTFIX _d )
set_target_properties( target_name PROPERTIES RELWITHDEBINFO_POSTFIX _rd )
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
James Ihrig
Sent: Monday, August 09, 2010 1:23 PM
To: cmake@cmake.org
Subject: [CMake] Eliminate Debug/Release directories and name executables based
on configuration
Hello,
I'm using CMake for Visual Studio as well as Makefiles for Linux. In windows,
debug and release directories seem to be added for the executables.
I actually would like to do three things:
1) Test for a debug or release build
2) Name the executable created based on it's build. (myProgram_d.exe for debug,
myProgram.exe for release.)
3) Place the output executables into the bin directory without debug and
release directories.
I have not found a way to test for the build type but I have tried these
together, and in various combinations:
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/../Demo/bin)
set(RUNTIME_OUTPUT_BINARY ${PROJECT_BINARY_DIR}/../Demo/bin)
set(RUNTIME_OUTPUT_DIRECTORY_DEBUG ${PROJECT_BINARY_DIR}/../Demo/bin)
set(RUNTIME_OUTPUT_DIRECTORY_RELEASE ${PROJECT_BINARY_DIR}/../Demo/bin)
set(RUNTIME_OUTPUT_NAME_DEBUG demo_d.exe)
set(RUNTIME_OUTPUT_NAME_RELEASE demo.exe)
The closest I can come are these executables:
Demo\bin\Debug\helloDemo.exe
Demo\bin\Release\helloDemo.exe
What I want is:
Demo\bin\demo_d.exe
Demo\bin\demo.exe
Any help or suggestions would be greatly appreciated!
-Jim
P.S.
For anyone curious what my main CMakeLists.txt looks like, here it is:
http://codepad.org/Yuev7TWJ
___
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] Auto detect IDL changes
I ran into this problem using Visual Studio 2008 and wrote up a macro to
generate the add_custom_command for each idl file. The function will rerun the
build command whenever the idl file is modified. There is very little
documentation for working with idl files online, so I hope this helps you.
Variables:
IDL_H_FILES: Generated header files
IDL_C_FILES: Generated C files
IDL_OUTPUT_LOC: The location where you want the build products to be
placed
idl_file1.idl ...: A list of idl files that you want to run the macro
against.
#IDL_COMPILE( IDL_H_FILES_VAR IDL_C_FILES_VAR IDL_OUTPUT_LOC_VAR idl_file1.idl
idl_file2.idl ... )
MACRO( IDL_COMPILE IDL_H_FILES_VAR IDL_C_FILES_VAR IDL_OUTPUT_LOC )
IF( WIN32 )
SET( ${IDL_H_FILES} )
SET( ${IDL_C_FILES} )
FOREACH( INDEX ${ARGN} )
GET_FILENAME_COMPONENT( INFILE_NAME ${INDEX} NAME_WE )
GET_FILENAME_COMPONENT( INFILE_PATH ${INDEX} PATH )
SET( OUT_H_FILE ${INFILE_NAME}.h )
SET( OUT_H_FILE_FULL ${IDL_OUTPUT_LOC}/${OUT_H_FILE} )
SET( OUT_IC_FILE ${INFILE_NAME}_i.c )
SET( OUT_IC_FILE_FULL ${IDL_OUTPUT_LOC}/${OUT_IC_FILE} )
SET( OUT_PC_FILE ${INFILE_NAME}_p.c )
SET( OUT_PC_FILE_FULL ${IDL_OUTPUT_LOC}/${OUT_PC_FILE} )
SET( OUT_TLB_FILE ${INFILE_NAME}.tlb )
SET( OUT_TLB_FILE_FULL ${IDL_OUTPUT_LOC}/${OUT_TLB_FILE} )
IF( ${ZEBRA_PLATFORM} STREQUAL x32 )
SET( DEST_PLATFORM win32 )
ELSE( ${ZEBRA_PLATFORM} STREQUAL x32 )
SET( DEST_PLATFORM x64 )
ENDIF( ${ZEBRA_PLATFORM} STREQUAL x32 )
ADD_CUSTOM_COMMAND( OUTPUT ${OUT_H_FILE_FULL} ${OUT_IC_FILE_FULL}
${OUT_TLB_FILE_FULL}
COMMAND midl
ARGS \${INDEX}\ /I \${INFILE_PATH}\ /char signed /env
${DEST_PLATFORM} /Oicf /tlb \${OUT_TLB_FILE}\ /out \${IDL_OUTPUT_LOC}\ /h
\${OUT_H_FILE}\ /iid \${OUT_IC_FILE}\ /proxy \${OUT_PC_FILE}\
MAIN_DEPENDENCY ${INDEX}
)
LIST( APPEND ${IDL_H_FILES_VAR} ${OUT_H_FILE_FULL} )
LIST( APPEND ${IDL_C_FILES_VAR} ${OUT_IC_FILE_FULL} )
ENDFOREACH( INDEX )
ENDIF( WIN32 )
ENDMACRO( ZEBRA_IDL_COMPILE )
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
avner cohen
Sent: Sunday, August 02, 2009 11:33 AM
To: cmake@cmake.org
Subject: [CMake] Auto detect IDL changes
Greetings all,
I've been deploying Cmake into our project for the past 2-3 months and just up
with a problem I was unable to resovle so far.
As part of the work we do, during Cmake execution, we also compile our C++ IDLs.
I've managed to come up with a clean EXECUTE_PROCESS code that will run this on
all OSs.
The problem is that IDLs do not change on a frequent basis and the fact that
these are added to the cmake makes it very generic, but forces a full build
with every build request.
Is there any way to come up with a way to identify the case where IDLs are
changed only than execute the compilation code?
Thanks in Advance,
Avner Cohen.
___
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] How do you make a 64-bit NSIS installer for Windows?
My company is trying to package our software on Windows using NSIS in 32-bit and 64-bit but the install path always assumes that the package is 32-bit. If you are on a 64-bit machine, 32-bit and 64-bit NSIS installers use C:\Program Files (x86) as the install path. The proper way for a 64-bit installer is to have the path be C:\Program Files on a 64-bit machine and not allow an install on a 32-bit machine. Is there any support for this in CMake or does the functionality need to be added? Thanks, Keith ___ 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] How do you make a 64-bit NSIS installer for Windows?
Thanks for the quick reply. I created a feature request in mantis. http://public.kitware.com/Bug/view.php?id=9094 Keith -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Tuesday, June 02, 2009 8:37 AM To: Keith Gardner Cc: cmake@cmake.org Subject: Re: [CMake] How do you make a 64-bit NSIS installer for Windows? The functionality needs to be added. Patches attached to feature requests in the bug tracker are always welcome. :-) Basically, we need some bit-ness detection code in the Modules/NSIS.template.in file. On Tue, Jun 2, 2009 at 9:21 AM, Keith Gardner kgard...@zebraimaging.com wrote: My company is trying to package our software on Windows using NSIS in 32-bit and 64-bit but the install path always assumes that the package is 32-bit. If you are on a 64-bit machine, 32-bit and 64-bit NSIS installers use C:\Program Files (x86) as the install path. The proper way for a 64-bit installer is to have the path be C:\Program Files on a 64-bit machine and not allow an install on a 32-bit machine. Is there any support for this in CMake or does the functionality need to be added? Thanks, Keith ___ 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.50/2150 - Release Date: 06/02/09 06:47:00 ___ 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] Set output path without additional Debug/Release at the end
Andreas,
What you will have to do is for every target, set the property prefix to
../. There is no other way I have found to do this.
Example:
ADD_EXECUTABLE( ${PROJECT_NAME}
${SRCS}
)
SET_TARGET_PROPERTIES( ${PROJECT_NAME} PROPERTIES PREFIX ../ )
Keith
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Andreas
Sent: Friday, April 24, 2009 6:27 AM
To: cmake@cmake.org
Subject: [CMake] Set output path without additional Debug/Release at the
end
Dear CMake users,
I would like to set the output path of my library to
C:/name1/Debug/name2/ (debug configuration) and
C:/name1/Release/name2/ (release configuration).
If I use
SET(LIBRARY_OUTPUT_PATH D:/name1/${CMAKE_CFG_INTDIR}/name2/)
an additional Debug / Release is added at the end of the path (--
C:/name1/Debug/name2/Debug).
Is there any way *not to add an additional* Debug / Release at the end?
Thanks,
Andreas
___
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
