Re: [cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes
Stephen Kelly steveire@... writes: Matthew Woehlke wrote: Perhaps that is a misreading on my part, but I was getting the impression this change would make it so that imported targets can only ever be SYSTEM. I didn't really make that clear as the discussion developed, but yes, I think it makes sense to allow treating the include directories as non-system somehow, even if not by default. I've pushed the IMPORTED-target-SYSTEM-includes topic to my clone for review. It introduces a policy-controlled default handling of INTERFACE_INCLUDE_DIRECTORIES from IMPORTED targets as SYSTEM. It also introduces a default-initialized target property to get the opposite behavior in the cases where that is wanted. It also introduces a SYSTEM option to target_link_libraries because I'd already written the patch, but I'm not certain that's needed anymore. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/29/2013 11:14 AM, Stephen Kelly wrote:
Another option would be not to have the VERSION in the signature, but
always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary
being run, so it relieves users of the need to additionally maintain the
VERSION here and figure out how that maps to their minimum cmake version.
A project may wish to update to a newer required CMake version for some
other feature but is not ready to port their header generation. We
could define the versions w.r.t. the CMake version and make VERSION
optional. If not present use CMAKE_MINIMUM_VERSION_REQUIRED. If
present then fail if VERSION is newer than CMAKE_MINIMUM_VERSION_REQUIRED.
I put an untested pseudo-code version of this in my compiler_features
branch. It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in Modules/CompilerFeatures/${ID}-${LANG}.cmake
instead?
We also need a plan to phase out support for ancient versions in the
future.
Any ideas on how to do that?
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in Modules/CompilerFeatures/${ID}-${LANG}.cmake
instead?
Why do you need to check features of a compiler not currently enabled?
Without being enabled we don't even know what version of the other
compiler to check.
I thought the idea was to specify in target_compiler_features the
features needed so they would be published in the target interface.
Then whatever compiler is used can have its feature set tested against
the requirements. This would work both in-project and in consumers, no?
We also need a plan to phase out support for ancient versions in the
future.
Any ideas on how to do that?
Perhaps we can document for each value of CMAKE_MINIMUM_VERSION_REQUIRED
the oldest VERSION value supported. That way it is up to the project
author to update VERSION and port code when bumping the minimum required
version of CMake. It will allow us to move forward but give projects
a long grace period.
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake.
Otherwise I wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in
Modules/CompilerFeatures/${ID}-${LANG}.cmake instead?
Why do you need to check features of a compiler not currently enabled?
Without being enabled we don't even know what version of the other
compiler to check.
CMake has the information for all compilers, and the idea was to use that
information to generate a header for use with all of them.
Stephen Kelly wrote:
The header file would have the preprocessor tests and version checks for
the known compilers. That is, the generated header file would be the same
on all platforms, and would look something like qcompilerdetection.h, but
with a customizable prefix for the macros.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7655
However, thinking about it again, I think you're right that that is not
necessary. The built package and generated header is compiler/platform
specific anyway, unlike qcompilerdetection.h, which is a source file
identical in the packages for all platforms.
I thought the idea was to specify in target_compiler_features the
features needed so they would be published in the target interface.
Then whatever compiler is used can have its feature set tested against
the requirements. This would work both in-project and in consumers, no?
Yes, I went on something of a tangent here.
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/30/2013 08:15 AM, Stephen Kelly wrote: However, thinking about it again, I think you're right that that is not necessary. Okay, it can always be factored out into separate files later anyway. I thought the idea was to specify in target_compiler_features the features needed so they would be published in the target interface. Then whatever compiler is used can have its feature set tested against the requirements. This would work both in-project and in consumers, no? Yes, I went on something of a tangent here. BTW, I think a better name may be language features rather than compiler features because we are declaring features of language versions and variants, not of the compilers. It is only in the implementation that we need to deal with compiler support for the features. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CMake 2.8.12-rc2 Released
The CMake 2.8.12 release candidate stream continues! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Some of the notable changes in this release are: - Introduced target_compile_options command - Specify compile options to use when compiling a given target. Supports PUBLIC, PRIVATE, and INTERFACE options. PRIVATE and PUBLIC items will populate the COMPILE_OPTIONS property of the target. PUBLIC and INTERFACE items will populate the INTERFACE_COMPILE_OPTIONS property of the target. Supports generator expressions. - Introduced add_compile_options command - Adds options to the compiler command line for sources in the current directory and below. Supports generator expressions. - Introduced CMake Policy 21: - It is now an error to add relative paths to the INCLUDE_DIRECTORIES target property. - Introduced CMake Policy 22: - Target properties matching (IMPORTED_)LINK_INTERFACE_LIBRARIES(_CONFIG) are ignored, and will no longer be populated by the target_link_libraries command. It is now an error to populate the properties directly in user code. Instead use the INTERFACE keyword with target_link_libraries, or the target property INTERFACE_LINK_LIBRARIES. - Introduced CMake Policy 23: - Plain and keyword target_link_libraries signatures cannot be mixed for a given target when this policy is enabled. Once PUBLIC,PRIVATE, or INTERFACE keywords are used, all subsequent target_link_libraries calls to the target must use one of these keywords. - Introduced: Support for RPATH under OSX - Please see the blog post by Clinton Stimpson about using RPATH on OSX (http://www.kitware.com/blog/home/post/510) - CMake: New PUBLIC PRIVATE and INTERFACE options for target_link_libraries - CMake: New ALIAS targets feature - CMake: Automatically process Headers directory of Apple Frameworks as a usage requirement - CMake: File command now supports the GENERATE command to produce files at generate time - CMake: target_include_directories now supports the SYSTEM parameter - CMake: Add support for Java in cross compilation toolchains - CMake: Improved support for the IAR toolchain - CMake: Improved support for the ARM toolchain under Visual Studio - CMake: Improvements to the Visual Studio Generators Including - Separate compiler and linker PDB files - Support for subdirectory MSBuild projects - Support for assembly code to VS10 - Support for Windows CE to VS11 - CMake: Added COMPILE_OPTIONS target property. - CMake: Added INTERFACE_LINK_LIBRARIES added as a property to targets - CMake: Now supports .zip files with the tar command - CMake: try_compile now supports multiple source files - CMake: Optimized custom command dependency lookup - CMake: Removal of configured files will retrigger CMake when issuing a build command - CMake: Ninja now tracks custom command generated files that aren't listed as output - CMake: Added generator expression support for compiler versions - CMake-Gui: Add search functions for Output window - CTest: Improved memory checker support - FindGTK2: General Improvements - FindCUDA: Multiple improvements to the custom commands The bug tracker change log page for this version is at: http://public.kitware.com/Bug/changelog_page.php?version_id=112 The complete list of changes in this rc since the previous release can be found at: http://www.cmake.org/Wiki/CMake/ChangeLog 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
