Re: [cmake-developers] Question about ALIAS targets
On Monday, 5 June 2017 22:45:26 BST Stephen Kelly wrote: > Brad King wrote: > > Steve, is there any reason for the restriction other than not implementing > > more use cases up front? > > There may be more information in the mailing list archives, but as far as I > remember, yes - we wanted to be conservative because we didn't know more > use-cases. Additionally, we didn't know the impact of making the feature > more unrestricted. If you want to see an example use case, I found that c-ares were trying to ALIAS an IMPORTED library in their package config file to make it convenient for a downstream project to explicitly link against a static or shared library (if available), or link against "either" if they don't care: https://github.com/c-ares/c-ares/blob/97f8b14c/c-ares-config.cmake.in If c-ares is compiled with both static and shared options, it will produce c-ares::cares (shared) and c-ares::cares_static (static) exported targets. Otherwise, if only one of the static or shared options is specified, it will always just build and export a c-ares::cares target. Obviously, the code won't work (and there is a pull request to fix it by using INTERFACE libraries at https://github.com/c-ares/c-ares/pull/108), and you may argue that this isn't the right solution to present downstreams with a "static vs shared vs don't care" choice, but I thought it might be interesting to show what developers are wanting to do with this. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument
On Thursday 30 July 2015 09:28:12 Brad King wrote: On 07/29/2015 03:58 PM, Alex Merry wrote: This is intended to be used from a settings file which is applied to a group of CMake projects. This allows the file to control which policies means that users of the settings file are not forced to use NO_POLICY_SCOPE (particularly important if the settings file did not originally have any policy settings in it, but later acquired some). Policies should not be set from a central hub, especially without the explicit permission of the including project (via NO_POLICY_SCOPE). Setting policies centrally breaks their compatibility model. The whole point is that the old behavior is preserved (possibly with a warning) until the project whose code triggers the policy is modified to address it. By setting a policy on behalf of the project calling include() you could silence warnings about behavior changes or even introduce errors. Each project author needs a chance to see their own policy warnings and address them accordingly. I should perhaps explain our use case: KDE provides the module KDECompilerSettings, which set a bunch of default compiler settings we think are generally useful for KDE software projects (extra warnings, feature macros for libraries and so on). One of those settings is the compiler visibility stuff (CMAKE_CXX_VISIBILITY_PRESET is set to hidden and CMAKE_VISIBILITY_INLINES_HIDDEN is set to 1). CMP0063 now causes a whole bunch of warnings to appear across a load of projects where there are executable targets. These warnings are because of a setting in the KDECompilerSettings, so it is natual to want to resolve the issue there. We'd like to set the policy to NEW, because the new behaviour is sensible, and we'd consider any project that was broken by the change to already to be in need of fixing, because relying on the old behaviour is non-portable (due to DLL export behaviour). We'd rather have a hard error (even at build time instead of configure time) with a vanishingly small number of projects (hopefully none) than a warning on lots of projects that are almost certainly not affected. Now, sure, we could change every single project that includes this module to use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we tell people to use this module, it seems a very clunky approach. It means the module is at risk of leaking policy settings it didn't mean to (if it were to set policies for its own internal use), but it also means that, conceptually, you are asking users to opt-in to this particular behavoural change (because it happens to be implemented as a policy), but not to the other behavioural changes we make in the module (because they are implemented with variables). Of course, ideally, we'd like to policy change to have the same scope as the variable settings it accompanies. That doesn't seem to be possible to acheive, though (at least, not in a clean way) because of the separate stacks for policy scopes and variable scopes. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument
Add a PARENT_SCOPE argument to cmake_policy(SET) that makes the policy
apply to the parent (strong) scope - it will break out of exactly one
level of the policy stack.
This is intended to be used from a settings file which is applied to a
group of CMake projects. This allows the file to control which policies
apply only within the file and which apply to the project. It also means
that users of the settings file are not forced to use NO_POLICY_SCOPE
(particularly important if the settings file did not originally have any
policy settings in it, but later acquired some).
---
Source/cmCMakePolicyCommand.cxx| 19 +-
Source/cmMakefile.cxx | 14 +++--
Source/cmMakefile.h| 4 +-
Tests/PolicyScope/CMakeLists.txt | 73 +-
Tests/PolicyScope/FindFoo.cmake| 1 +
Tests/PolicyScope/IncludesUsesParentScope.cmake| 1 +
.../IncludesUsesParentScopeWithCMP0011New.cmake| 2 +
.../IncludesUsesParentScopeWithCMP0011Old.cmake| 2 +
Tests/PolicyScope/UsesParentScope.cmake| 3 +
9 files changed, 109 insertions(+), 10 deletions(-)
create mode 100644 Tests/PolicyScope/IncludesUsesParentScope.cmake
create mode 100644
Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011New.cmake
create mode 100644
Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011Old.cmake
create mode 100644 Tests/PolicyScope/UsesParentScope.cmake
diff --git a/Source/cmCMakePolicyCommand.cxx b/Source/cmCMakePolicyCommand.cxx
index 3ef6d35..5e249a5 100644
--- a/Source/cmCMakePolicyCommand.cxx
+++ b/Source/cmCMakePolicyCommand.cxx
@@ -65,9 +65,9 @@ bool cmCMakePolicyCommand
//
bool cmCMakePolicyCommand::HandleSetMode(std::vectorstd::string const args)
{
- if(args.size() != 3)
+ if(args.size() != 3 args.size() != 4)
{
-this-SetError(SET must be given exactly 2 additional arguments.);
+this-SetError(SET must be given 2-3 additional arguments.);
return false;
}
@@ -88,7 +88,20 @@ bool
cmCMakePolicyCommand::HandleSetMode(std::vectorstd::string const args)
return false;
}
- if(!this-Makefile-SetPolicy(args[1].c_str(), status))
+ bool include_parent = false;
+ if(args.size() == 4)
+{
+include_parent = true;
+if (args[3] != PARENT_SCOPE)
+ {
+ std::ostringstream e;
+ e SET given unexpected third argument \ args[3] \;
+ this-SetError(e.str());
+ return false;
+ }
+}
+
+ if(!this-Makefile-SetPolicy(args[1].c_str(), status, include_parent))
{
this-SetError(SET failed to set policy.);
return false;
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 57e33df..3859938 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -4791,7 +4791,8 @@ bool cmMakefile::PolicyOptionalWarningEnabled(std::string
const var)
}
bool cmMakefile::SetPolicy(const char *id,
- cmPolicies::PolicyStatus status)
+ cmPolicies::PolicyStatus status,
+ bool include_parent)
{
cmPolicies::PolicyID pid;
if (!cmPolicies::GetPolicyID(id, /* out */ pid))
@@ -4801,12 +4802,13 @@ bool cmMakefile::SetPolicy(const char *id,
this-IssueMessage(cmake::FATAL_ERROR, e.str());
return false;
}
- return this-SetPolicy(pid,status);
+ return this-SetPolicy(pid,status,include_parent);
}
//
bool cmMakefile::SetPolicy(cmPolicies::PolicyID id,
- cmPolicies::PolicyStatus status)
+ cmPolicies::PolicyStatus status,
+ bool include_parent)
{
// A REQUIRED_ALWAYS policy may be set only to NEW.
if(status != cmPolicies::NEW
@@ -4822,9 +4824,13 @@ bool cmMakefile::SetPolicy(cmPolicies::PolicyID id,
// Update the policy stack from the top to the top-most strong entry.
bool previous_was_weak = true;
for(PolicyStackType::reverse_iterator psi = this-PolicyStack.rbegin();
- previous_was_weak psi != this-PolicyStack.rend(); ++psi)
+ (previous_was_weak || include_parent) psi !=
this-PolicyStack.rend(); ++psi)
{
psi-Set(id, status);
+if (!previous_was_weak)
+ {
+ include_parent = false;
+ }
previous_was_weak = psi-Weak;
}
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 7938fcc..44a47f5 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -318,8 +318,8 @@ public:
/**
* Set, Push, Pop policy values for CMake.
*/
- bool SetPolicy(cmPolicies::PolicyID id, cmPolicies::PolicyStatus status);
- bool SetPolicy(const char *id, cmPolicies::PolicyStatus status);
+ bool SetPolicy(cmPolicies::PolicyID id, cmPolicies::PolicyStatus status,
bool include_parent = false);
+ bool SetPolicy(const char *id,
[cmake-developers] Strange behaviour with install(EXPORT)
Suppose you have a CMakeLists.txt file like = cmake_minimum_required(VERSION 2.8.12) project(Foo) add_library(Ext::Imported SHARED IMPORTED) add_library(FooDep SHARED main.cpp) install(TARGETS FooDep ARCHIVE DESTINATION lib LIBRARY DESTINATION lib ) add_library(FooMain SHARED main.cpp) target_link_libraries(FooMain PUBLIC Ext::Imported PRIVATE FooDep ) install(TARGETS FooMain EXPORT FooTargets ARCHIVE DESTINATION lib LIBRARY DESTINATION lib ) install(EXPORT FooTargets NAMESPACE Foo:: DESTINATION lib/cmake/Foo FILE FooTargets.cmake) = This fails with the error CMake Error: install(EXPORT FooTargets ...) includes target FooMain which requires target FooDep that is not in the export set. It is not obvious from what I have read of the documentation that this should happen, but (looking at the CMake code), this seems to be deliberate - the issue is in trying to populate IMPORTED_LINK_DEPENDENT_LIBRARIES for the exported target, it wants the private dependencies as well as the interface ones. So it wants FooDep to be EXPORTed, even though this may be a private internal library. However, removing the PUBLIC dependencies of FooMain suppresses this error, presumably because the INTERFACE_LINK_LIBRARIES property is not set, so cmTargetInternals::ComputeLinkInterfaceLibraries does not set iface.ExplicitLibraries for the target, so cmTargetInternals::ComputeLinkInterface does not add anything to iface.SharedDeps, which is what is used to populate IMPORTED_LINK_DEPENDENT_LIBRARIES. This difference in behaviour does not make sense. So either neither case should be an error, or both cases should be. However, I don't know which it is. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] A policy for Policies
On Saturday 06 June 2015 12:36:53 Stephen Kelly wrote: Hi, The documentation notes that Policies are not feature toggles: http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html However, the reality is that Policies *are* feature toggles because they are so long-lived. Users have no expectation that Policies will 'stop working', and happily set them to OLD and encourage others to do the same. I see this on StackOverflow all the time, and on the users mailing list. Code for Policies is also often complex. I often encounter Policies which are ancient and which get in the way of code clean up generally. We also encountered this with CMP0024 and CMP0026 getting in the way in 2013. The refactoring I'm doing now will encounter those two again. I'd also prefer to drop CMP0011 rather than deal with its complexity in my current refactoring. CMP0011 was introduced in 2009. I propose a policy that a Policy may be changed to REQUIRED_IF_USED in a release two years following the release which introduced it. Such a change will then result in an error if code attempts to set it to OLD, and recommend the user to use an older release or fix the code instead. I'm not sure the term REQUIRED_IF_USED is clear enough - I'm certainly confused by quite what you mean by it. The main reason for keeping policies around, as I see it, is to allow old projects to keep building with newer versions of CMake. The main questions are: how far back do we want this compatibility to go? and how selective do we want to allow developers to be about policies? However much we care about backwards compatilibity, I think it's reasonable to have a cut-off point for allowing setting individual policies back (as opposed to having them set back by cmake_minimum_required). That would hopefully encourage developers to clean up code that depends on old behaviour in order to use a useful new feature, which would in turn allow support for old policies to be dropped sooner. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake and intersphinx
On Saturday 21 March 2015 09:41:06 Gregor Jasny wrote: Hello, I wanted to start documenting our in-company CMake modules. Often I'd like to refer to some basic CMake commands. As far as I understand the intersphinx extension [1] should be able to provide that. To reference remote projects these need to provide a objects.inv mapping file. But thee mapping files were excluded from install by this commit: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c3cf36b3a1388bb9c3a71835 0c80eae0a41119d Would you consider re-adding these files? Or should 3rd parties host their own documentation sets somewhere? Thanks, Gregor [1] http://sphinx-doc.org/latest/ext/intersphinx.html This would also be useful for the extra-cmake-modules project. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: Helper macros for writing Find modules
On Tuesday 17 March 2015 15:41:17 Brad King wrote: On 03/13/2015 06:04 AM, Alex Merry wrote: For the extra-cmake-modules package, I wrote some macros to help with writing component-based Find modules, which are non-trivial to get right. The documentation for them can be found here: http://api.kde.org/ecm/module/ECMFindModuleHelpers.html I've found them incredibly useful in writing classic Find modules, where you just want to find a bunch of libraries and their associated headers, but you also need to account for the dependencies between those libraries. Thanks. I've read through the file here: http://quickgit.kde.org/?p=extra-cmake-modules.gita=blobf=modules/ECMFind ModuleHelpers.cmakehb=v1.8.0 # ecm_find_package_version_check(name) This one does not look relevant to CMake upstream. Yep, I can't imagine that being useful outside ECM. # ecm_find_package_parse_components(name # RESULT_VAR variable # KNOWN_COMPONENTS component1 [component2 [...]] # [SKIP_DEPENDENCY_HANDLING]) [snip] # ecm_find_package_handle_library_components(name # COMPONENTS component [component [...]] # [SKIP_DEPENDENCY_HANDLING]) # [SKIP_PKG_CONFIG]) These look like they take care of a lot of logic common to many find modules and could be useful upstream. They could also help make the find modules have a more consistent interface. I'd appreciate feedback on them from other upstream find module maintainers though. One comment is that they may be a little too all-encompassing and not very adaptable to slight variations from the standard cases. Perhaps that can be addressed with more options if needed. Also one could later factor some of the parts out into more granular helpers that could be used individually. I made some changes in a copy of this module for work that separated out the target creation, as well as adding debug/release support. I'll check about being allowed to release that work, but I doubt it'll be an issue. If we upstream any of these I think we could create a CMakeFindModuleHelpers module that includes FindPackageHandleStandardArgs and also provides other helpers. That way individual modules would only have to include one other module to get the helpers. That was pretty much what I was thinking of. Including FindPackageHandleStandardArgs seems sensible as well. The interface is a little unusual: you have to set up some information- providing variables before calling the macros to describe the information for each component. I think that is okay. The pre-set variables are more like tables of information AFAICT. Yep, that's exactly what they are. FYI, see this change where I dropped a recommendation for find module authors that IIRC came from your ECM work: Help: Drop FeatureSummary example in cmake-developer.7 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8235effe I think it is a good convention to have, and I'm glad ECM has it, but would prefer it be established upstream only with a sweeping effort to cover many of the existing modules in a consistent way. One issue I realised with this after the fact is that it works poorly with *Config.cmake files - if there is no find module, and the package is not found, the URL telling you how to get hold of it would be missing unless you add it at the find_package call site. FindWayland.cmake (which I would also submit for inclusion to CMake). I haven't looked at FindWayland in detail yet, but is its design generic enough to be able to find varying Wayland implementations in the future? Should it be called FindWeston instead? Perhaps this is a discussion for a future thread after the above is resolved though. As far as I'm aware, the stuff that FindWayland finds is libraries designed for writing a wayland implementation - ie: it's the protocol layer. It was originally written partly to benefit KWin, which at least plans to be a Wayland implementation of its own. I may be wrong about that, though. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] RFC: Helper macros for writing Find modules
For the extra-cmake-modules package, I wrote some macros to help with writing component-based Find modules, which are non-trivial to get right. The documentation for them can be found here: http://api.kde.org/ecm/module/ECMFindModuleHelpers.html I've found them incredibly useful in writing classic Find modules, where you just want to find a bunch of libraries and their associated headers, but you also need to account for the dependencies between those libraries. The interface is a little unusual: you have to set up some information- providing variables before calling the macros to describe the information for each component. As an example, see http://quickgit.kde.org/?p=extra-cmake-modules.gita=blobh=c5a56c1635d03acdaf5ccd780b9a358d6f6655fdhb=4f81d1a92e4ccc2ce7b33d2860397a526b1a4d2ff=find-modules%2FFindWayland.cmake (which I would also submit for inclusion to CMake if this is accepted). Would this be something that might be included in CMake? I have some ideas about how to extend it to be able to account for debug vs release libraries as well (roughly following a simplified version of the pattern of the FindQt4 module). Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving Vim support in CMake
On Monday 26 January 2015 18:22:41 Ben Boeckel wrote: On Mon, Jan 26, 2015 at 22:39:00 +, Alex Merry wrote: Maybe it's just my colour scheme - I'll have a play with the colour settings when I have some free time. FWIW, I use neverland-darker, a 256-color scheme. Looking at it with an 8-color scheme does indeed have it all being the same. 'Label' seems to at least be different than 'String' in all the default color schemes whereas 'Constant' is the same as 'String' there. Unfortunately, there's no 'Variable' highlighting group and if we don't stick to the defaults available, none of the colorschemes will know what to do with it :/ . 'Tag' also seems like it might be viable. Maybe making cmakeArguments - Constant and cmakeVariableValue - Identifier would work better? Strings are the same as unquoted words there though :/ . That would explain it. I think variables are used in strings enough that making them different colours on standard colour schemes is sensible. I would argue that distinguishing variables and constants, say, is less important. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving Vim support in CMake
On Monday 26 January 2015 11:00:44 Ben Boeckel wrote: On Mon, Jan 26, 2015 at 11:00:05 -0500, Ben Boeckel wrote: Odd; attached is an HTML dump from Vim for what I see (:TOhtml) where variable expansions are highlighted in strings just like outside of strings. Probably help if I actually attached the file :/ . --Ben Maybe it's just my colour scheme - I'll have a play with the colour settings when I have some free time. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving Vim support in CMake
On Wednesday 21 January 2015 16:17:35 Ben Boeckel wrote: List of improvements to the syntax file: - drop support for 7.0 (which is 7.5 years old now); - add support for Lua-style comments; - update the list of system variables; - update the list of operators; - make only commands case-insensitive; - update the list of built-in commands (and deprecated ones); - highlight user-defined function and macro calls; and - tweak colors a bit. Much needed, especially updating the list of commands and operators, thanks! However, I'm missing having variables highlighted in a different colour, especially when they appear in strings. Also, do you know if it's possible to make command and operator highlighting context-sensitive? For example, in add_command(COMMAND foo), COMMAND is highlighted because it is in the list of operators, and I've got a command that takes a LINK_LIBRARIES keyword argument, which is highlighted as a deprecated command. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Friday 24 October 2014 10:02:31 Brad King wrote:
On 10/24/2014 09:50 AM, Brad King wrote:
With 3.0 we see the list of headers accumulate. With 3.1 just the
first one works and the rest do not.
I bisected it down to:
commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49
Author: Ben Boeckel ben.boec...@kitware.com
Date: Wed Mar 12 14:01:45 2014 -0400
cmDefinitions: Don't store parent lookups
When looking up scopes, it is faster to not store the lookup locally to
keep the maps smaller and avoid extra allocations and rebalancing.
-Brad
Which matches my trimmed-down testcase:
-
cmake_minimum_required(VERSION 3.0)
project(Minimal NONE)
function(test_append varname entry)
list(APPEND ${varname} ${entry})
set(${varname} ${${varname}} PARENT_SCOPE)
set(${varname} ${${varname}} PARENT_SCOPE)
endfunction()
test_append(blah entry1)
message(STATUS blah=${blah})
test_append(blah entry2)
message(FATAL_ERROR blah=${blah})
-
It's that double-setting of the variable in the parent scope that seems to be
the killer.
Alex
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Friday 24 October 2014 10:20:42 Brad King wrote:
On 10/24/2014 10:02 AM, Brad King wrote:
I bisected it down to:
commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49
Author: Ben Boeckel ben.boec...@kitware.com
Date: Wed Mar 12 14:01:45 2014 -0400
cmDefinitions: Don't store parent lookups
When looking up scopes, it is faster to not store the lookup locally
to
keep the maps smaller and avoid extra allocations and rebalancing.
Here is a minimal standalone example:
$ cat regression.cmake
function(func var_name)
list(APPEND ${var_name} value)
set(${var_name} ${${var_name}} PARENT_SCOPE)
set(${var_name} ${${var_name}} PARENT_SCOPE)
endfunction()
func(var)
message(STATUS var=[${var}])
func(var)
message(STATUS var=[${var}])
$ cmake-3.0 -P regression.cmake
-- var=[value]
-- var=[value;value]
$ cmake-3.1 -P regression.cmake
-- var=[value]
-- var=[value]
-Brad
Even simpler:
---
cmake_minimum_required(VERSION 3.0)
project(Minimal NONE)
function(test_set)
set(blah value2)
message(STATUS before PARENT_SCOPE blah=${blah})
set(blah ${blah} PARENT_SCOPE)
message(STATUS after PARENT_SCOPE blah=${blah})
endfunction()
set(blah value1)
test_set()
message(FATAL_ERROR in parent scope, blah=${blah})
--
With CMake master:
-- before PARENT_SCOPE blah=value2
-- after PARENT_SCOPE blah=value1
CMake Error at CMakeLists.txt:13 (message):
in parent scope, blah=value2
With CMake 3.0.2:
-- before PARENT_SCOPE blah=value2
-- after PARENT_SCOPE blah=value2
CMake Error at CMakeLists.txt:13 (message):
in parent scope, blah=value2
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_compile_features remaining issues
On 10/04/14 09:46, Stephen Kelly wrote: Alex Merry wrote: On 28/03/14 15:16, Stephen Kelly wrote: The target_compile_features topic in my clone is almost ready to merge to next. Having looked through the docs for the topic, the thing that is missing that I'd like to see is a way (probably a variable) to specify the default enabled features for all targets in the project (or subdir). I guess the idiom for that would be a add_compile_features command which populates a COMPILE_FEATURES directory property. See the COMPILE_OPTIONS directory and target properties for comparison. Yep, that would work. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_compile_features remaining issues
On 28/03/14 15:16, Stephen Kelly wrote: The target_compile_features topic in my clone is almost ready to merge to next. Having looked through the docs for the topic, the thing that is missing that I'd like to see is a way (probably a variable) to specify the default enabled features for all targets in the project (or subdir). In fact, that's sort of what I'd expect from CMAKE_CXX_COMPILE_FEATURES, and I'd expect that functionality to be in something like CMAKE_CXX_AVAILABLE_FEATURES or something. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Better find module developer documentation
On 27/03/14 14:33, Brad King wrote: On 03/26/2014 03:02 PM, Alex Merry wrote: I wrote some documentation on how to write a find module for KDE's extra-cmake-modules project, and Stephen suggested upstreaming it. So attached is a patch that does that. Thanks for working on this. I like the tutorial-style presentation. First, a few reST style comments: * Paragraphs ending in : :: can be simplified to ::. * CMake code blocks should use .. code-block:: cmake rather than a plain literal block if the code in the block is valid CMake code (as against containing placeholders as in command signature documentation). * Indented blocks where the amount of indentation can be chosen should use 2 spaces instead of 1. Note that this changes the recommendations from the Foo_LIBRARIES, Foo_INCLUDES and Foo_DEFINITIONS variables to creating imported targets (which are much easier and less error-prone to use). Providing imported targets is nice, and preferred by KDE, but is not a requirement for upstream modules. Most existing modules have not been updated to provide them. Using imported targets throughout a project requires additional effort when creating package configuration files to ensure dependencies that name imported targets have them available. The docs should explain both approaches. Then explain why imported targets are preferred but that since the approach is newer not all existing modules have been updated. We need to maintain the list of example variable names. The difference between Foo_LIBRARY and Foo_LIBRARIES needs to be clearly explained, and not just in the sample module section. Attached patch contains the suggested changes. I still went with recommending Foo_VERSION over Foo_VERSION_STRING, because there is really no purpose served by having two different names for the version variable, one for packages and one for find modules. I kept in a note about Foo_VERSION_STRING, though. Alex From ee0fae3911c0646d7568a114fb55e6ad24958eec Mon Sep 17 00:00:00 2001 From: Alex Merry alex.me...@kde.org Date: Wed, 26 Mar 2014 18:54:02 + Subject: [PATCH] Rewrite the find module developer documentation As well as the traditional variables, providing imported targets is suggested, and the relative advantages and disadvantages briefly discussed. A mini-tutorial walking through creating a simple find module is provided. This changes the recommended version variable from Foo_VERSION_STRING to Foo_VERSION, because there is really no need to have different variable names for package version files vs. find modules. It notes the old variable name, though, and suggests setting it for compatibility. --- Help/manual/cmake-developer.7.rst | 545 ++ 1 file changed, 370 insertions(+), 175 deletions(-) diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst index d025d63..7f31970 100644 --- a/Help/manual/cmake-developer.7.rst +++ b/Help/manual/cmake-developer.7.rst @@ -664,213 +664,408 @@ For example, a ``Modules/Findxxx.cmake`` module may contain: code endmacro() +After the top documentation block, leave a *BLANK* line, and then add a +copyright and licence notice block like this one (change only the year +range and name) + +.. code-block:: cmake + + #= + # Copyright 2009-2011 Your Name + # + # 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.) + +Test the documentation formatting by running +``cmake --help-module module-name``, and also by enabling the +``SPHINX_HTML`` and ``SPHINX_MAN`` options to build the documentation. +Edit the comments until generated documentation looks satisfactory. To +have a .cmake file in this directory NOT show up in the modules +documentation, simply leave out the ``Help/module/module-name.rst`` +file and the ``Help/manual/cmake-modules.7.rst`` toctree entry. + + Find Modules A find module is a ``Modules/Findpackage.cmake`` file to be loaded by the :command:`find_package` command when invoked for ``package``. -We would like all ``FindXxx.cmake`` files to produce consistent variable -names. Please use the following consistent variable names for general use. +The primary task of a find module is to determine whether a package +exists on the system, set the ``package_FOUND`` variable to reflect +this and provide any variables, macros and imported targets required to +use the package. + +The traditional
[cmake-developers] [PATCH] Better find module developer documentation
I wrote some documentation on how to write a find module for KDE's extra-cmake-modules project, and Stephen suggested upstreaming it. So attached is a patch that does that. Note that this changes the recommendations from the Foo_LIBRARIES, Foo_INCLUDES and Foo_DEFINITIONS variables to creating imported targets (which are much easier and less error-prone to use). Alex From 2dc24347a65c1aeec6410dc265e6b0047b6a2317 Mon Sep 17 00:00:00 2001 From: Alex Merry alex.me...@kde.org Date: Wed, 26 Mar 2014 18:54:02 + Subject: [PATCH] Rewrite the find module developer documentation The recommendation now is to try to match what config files do, ie: create imported targets. This also walks through creating a sample find module. Modules that provide components are glossed over currently, despite being difficult to implement correctly. --- Help/manual/cmake-developer.7.rst | 408 +- 1 file changed, 227 insertions(+), 181 deletions(-) diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst index d025d63..0648cf8 100644 --- a/Help/manual/cmake-developer.7.rst +++ b/Help/manual/cmake-developer.7.rst @@ -664,124 +664,137 @@ For example, a ``Modules/Findxxx.cmake`` module may contain: code endmacro() -Find Modules - - -A find module is a ``Modules/Findpackage.cmake`` file to be loaded -by the :command:`find_package` command when invoked for ``package``. - -We would like all ``FindXxx.cmake`` files to produce consistent variable -names. Please use the following consistent variable names for general use. - -Xxx_INCLUDE_DIRS - The final set of include directories listed in one variable for use by client - code. This should not be a cache entry. - -Xxx_LIBRARIES - The libraries to link against to use Xxx. These should include full paths. - This should not be a cache entry. - -Xxx_DEFINITIONS - Definitions to use when compiling code that uses Xxx. This really shouldn't - include options such as (-DHAS_JPEG)that a client source-code file uses to - decide whether to #include jpeg.h - -Xxx_EXECUTABLE - Where to find the Xxx tool. - -Xxx_Yyy_EXECUTABLE - Where to find the Yyy tool that comes with Xxx. - -Xxx_LIBRARY_DIRS - Optionally, the final set of library directories listed in one variable for - use by client code. This should not be a cache entry. +After the top documentation block, leave a *BLANK* line, and then add a +copyright and licence notice block like this one (change only the year +range and name):: -Xxx_ROOT_DIR - Where to find the base directory of Xxx. - -Xxx_VERSION_Yy - Expect Version Yy if true. Make sure at most one of these is ever true. - -Xxx_WRAP_Yy - If False, do not try to use the relevant CMake wrapping command. - -Xxx_Yy_FOUND - If False, optional Yy part of Xxx sytem is not available. - -Xxx_FOUND - Set to false, or undefined, if we haven't found, or don't want to use Xxx. - -Xxx_NOT_FOUND_MESSAGE - Should be set by config-files in the case that it has set Xxx_FOUND to FALSE. - The contained message will be printed by the find_package() command and by - find_package_handle_standard_args() to inform the user about the problem. - -Xxx_RUNTIME_LIBRARY_DIRS - Optionally, the runtime library search path for use when running an - executable linked to shared libraries. The list should be used by user code - to create the PATH on windows or LD_LIBRARY_PATH on unix. This should not be - a cache entry. - -Xxx_VERSION_STRING - A human-readable string containing the version of the package found, if any. + #= + # Copyright 2009-2011 Your Name + # + # 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.) -Xxx_VERSION_MAJOR - The major version of the package found, if any. +Test the documentation formatting by running +``cmake --help-module module-name``, and also by enabling the +``SPHINX_HTML`` and ``SPHINX_MAN`` options to build the documentation. +Edit the comments until generated documentation looks satisfactory. To +have a .cmake file in this directory NOT show up in the modules +documentation, simply leave out the ``Help/module/module-name.rst`` +file and the ``Help/manual/cmake-modules.7.rst`` toctree entry. -Xxx_VERSION_MINOR - The minor version of the package found, if any. -Xxx_VERSION_PATCH - The patch version of the package found, if any. +Find Modules + -You do not have to provide all of the above variables. You should provide -Xxx_FOUND under most circumstances. If Xxx
Re: [cmake-developers] FindFoo.cmake and COMPONENTS
On 26/03/14 22:28, Ben Boeckel wrote: [ Sorry for stealing the thread, but this might help spawn off a follow-up patch for COMPONENT-handling docs. ] On Wed, Mar 26, 2014 at 19:02:40 +, Alex Merry wrote: Modules that provide components are glossed over currently, despite being difficult to implement correctly. Hmm, I wrote one recently[1] and it didn't seem *too* hard. What sort of hidden pitfalls are there? One I can think of (that isn't handled in that Find module) is dependencies between components. *goes to look at the helper module[0] he wrote* Actually, yeah, it's mainly the dependency handling that's hairy. There are couple of other things you have to be aware of; for instance, I've seen several find modules try to give all the components to pkg_check_modules() at once, but you can't do that (pkg_check_modules finds everything or nothing). Alex [0]: https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository/revisions/master/entry/modules/ECMFindModuleHelpers.cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Fix find_dependency macro version argument
Recent commits broke the version argument handling, as the set variable
name is different to the used variable name. First attached patch fixes
this. The second one clears the variable again at the end of the macro,
to match the other variables.
Alex
From b82c9c6ff78582254a540b83fad9cc7c98b88479 Mon Sep 17 00:00:00 2001
From: Alex Merry alex.me...@kde.org
Date: Wed, 26 Feb 2014 11:41:35 +
Subject: [PATCH 1/2] find_dependency: use correct version variable name
The code set cmake_fd_version, but used ${version}.
---
Modules/CMakeFindDependencyMacro.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Modules/CMakeFindDependencyMacro.cmake b/Modules/CMakeFindDependencyMacro.cmake
index 08c4990..cf0206b 100644
--- a/Modules/CMakeFindDependencyMacro.cmake
+++ b/Modules/CMakeFindDependencyMacro.cmake
@@ -50,7 +50,7 @@ macro(find_dependency dep)
_CMAKE_${dep}_TRANSITIVE_DEPENDENCY
)
-find_package(${dep} ${version}
+find_package(${dep} ${cmake_fd_version}
${cmake_fd_exact_arg}
${cmake_fd_quiet_arg}
${cmake_fd_required_arg}
--
1.9.0
From 1cf1b5a33207e64d6bec59be659b62e8afe2ae2d Mon Sep 17 00:00:00 2001
From: Alex Merry alex.me...@kde.org
Date: Wed, 26 Feb 2014 11:41:48 +
Subject: [PATCH 2/2] find_dependency: unset cmake_fd_version variable at end
of macro
This matches the other macro variables.
---
Modules/CMakeFindDependencyMacro.cmake | 1 +
1 file changed, 1 insertion(+)
diff --git a/Modules/CMakeFindDependencyMacro.cmake b/Modules/CMakeFindDependencyMacro.cmake
index cf0206b..9334ba3 100644
--- a/Modules/CMakeFindDependencyMacro.cmake
+++ b/Modules/CMakeFindDependencyMacro.cmake
@@ -65,6 +65,7 @@ macro(find_dependency dep)
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND False)
return()
endif()
+set(cmake_fd_version)
set(cmake_fd_required_arg)
set(cmake_fd_quiet_arg)
set(cmake_fd_exact_arg)
--
1.9.0
--
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] [PATCH] fix version handling in find_dependency macro
The handling of the optional version argument in the find_dependency()
macro is just wrong. It is only set if ${ARGV1} (rather than ARGV1)
evaluates to true, and otherwise it remains unchanged from whatever its
previous value was (instead of being cleared).
Either of the attached patches fixes this.
Alex
From 57b10901f1f857bde0471f2be4398dace5c36253 Mon Sep 17 00:00:00 2001
From: Alex Merry k...@randomguy3.me.uk
Date: Sat, 22 Feb 2014 13:35:14 +
Subject: [PATCH] Always set version variable of find_dependency macro
If there is no ARGV1, that is fine; version will be made empty, and no
version will be passed to find_package().
---
Modules/CMakeFindDependencyMacro.cmake | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/Modules/CMakeFindDependencyMacro.cmake b/Modules/CMakeFindDependencyMacro.cmake
index 0f1f56d..c0a0ef7 100644
--- a/Modules/CMakeFindDependencyMacro.cmake
+++ b/Modules/CMakeFindDependencyMacro.cmake
@@ -29,9 +29,7 @@
macro(find_dependency dep)
if (NOT ${dep}_FOUND)
-if (${ARGV1})
- set(version ${ARGV1})
-endif()
+set(version ${ARGV1})
set(exact_arg)
if(${CMAKE_FIND_PACKAGE_NAME}_FIND_VERSION_EXACT)
set(exact_arg EXACT)
--
1.9.0
From d9da7a712d331e647d94fc12162e2c4df29ca7eb Mon Sep 17 00:00:00 2001
From: Alex Merry k...@randomguy3.me.uk
Date: Sat, 22 Feb 2014 13:35:14 +
Subject: [PATCH] Fix settings of the version variable of find_dependency macro
It should be reset before use, as this is a macro, and the test should
be against ARGV1, not its value.
---
Modules/CMakeFindDependencyMacro.cmake | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Modules/CMakeFindDependencyMacro.cmake b/Modules/CMakeFindDependencyMacro.cmake
index 0f1f56d..6f7dbe8 100644
--- a/Modules/CMakeFindDependencyMacro.cmake
+++ b/Modules/CMakeFindDependencyMacro.cmake
@@ -29,7 +29,8 @@
macro(find_dependency dep)
if (NOT ${dep}_FOUND)
-if (${ARGV1})
+set(version)
+if (ARGV1)
set(version ${ARGV1})
endif()
set(exact_arg)
--
1.9.0
--
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] [PATCH] Automoc documentation is misleading
On 04/02/14 12:45, Stephen Kelly wrote: Alex Merry wrote: If you have a header file like foo.h and the corresponding source file is, say, foo_win.cpp, automoc will never look at foo.h. ... unless you include moc_foo.cpp in foo_win.cpp, right? Yes; the fix is easy, but developers need to be aware that it is necessary. The attached patch makes the documentation clear on this point. Please create patches with `git format-patch`. It preserves authorship information. I did, and then removed the mail headers. I'll leave them there in future. I don't think there is a need to change the cmake-qt manual. I've pushed the rest to next for testing. OK. The wording did end up getting quite complicated in the cmake-qt manual. It might be worth having something like see the documentation for that property for exactly which files are scanned. Alex -- 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] [PATCH] Do not output transitive dependencies in feature_summary()
Currently, feature_summary() prints out all the transitive dependencies
of a package (those found with find_dependency() in a Config.cmake file)
in addition to the explicit dependencies looked for in a CMakeLists.txt.
This makes feature_summary() much less useful, because it is difficult
to see what is going on with such a long list, and the transitive
dependencies will not have information about the type and purpose set.
This adds a new package property, TRANSITIVE_DEPENDENCY, which is set by
find_dependency(). feature_summary() then omits any packages with that
set. If a CMakeLists.txt also finds the package directly and sets
information about it using set_package_properties(), the
TRANSITIVE_DEPENDENCY property is discarded.
---
Modules/CMakeFindDependencyMacro.cmake | 7 ++-
Modules/FeatureSummary.cmake | 25 +++--
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Modules/CMakeFindDependencyMacro.cmake
b/Modules/CMakeFindDependencyMacro.cmake
index 596c6fc..55a7ffa 100644
--- a/Modules/CMakeFindDependencyMacro.cmake
+++ b/Modules/CMakeFindDependencyMacro.cmake
@@ -11,7 +11,9 @@
# dependency. It is designed to be used in a packageConfig.cmake file, and it
# forwards the correct parameters for EXACT, QUIET and REQUIRED which were
# passed to the original :command:`find_package` call. It also sets an
-# informative diagnostic message if the dependency could not be found.
+# informative diagnostic message if the dependency could not be found, and
+# marks the package as a TRANSITIVE_DEPENDENCY for
+# :command:`feature_summary`.
#
#=
@@ -27,6 +29,8 @@
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
+include(FeatureSummary)
+
macro(find_dependency dep)
if (NOT ${dep}_FOUND)
if (${ARGV1})
@@ -46,6 +50,7 @@ macro(find_dependency dep)
endif()
find_package(${dep} ${version} ${exact_arg} ${quiet_arg} ${required_arg})
+set_package_properties(${dep} PROPERTIES TRANSITIVE_DEPENDENCY)
if (NOT ${dep}_FOUND)
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
${CMAKE_FIND_PACKAGE_NAME} could not be found because dependency ${dep} could
not be found.)
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND False)
diff --git a/Modules/FeatureSummary.cmake b/Modules/FeatureSummary.cmake
index b0f8e16..1d561b3 100644
--- a/Modules/FeatureSummary.cmake
+++ b/Modules/FeatureSummary.cmake
@@ -115,6 +115,7 @@
# [ DESCRIPTION description ]
# [ TYPE
(RUNTIME|OPTIONAL|RECOMMENDED|REQUIRED) ]
# [ PURPOSE purpose ]
+# [ TRANSITIVE_DEPENDENCY ]
# )
#
#
@@ -157,6 +158,12 @@
# the PURPOSE property is project-specific, so it cannot be set by the
# Find-module, but must be set in the project.
#
+# TRANSITIVE_DEPENDENCY: This indicates that the package has only been
+# found as a dependency of another package; it only makes sense to use
+# this option from a *Config.cmake file. A package will only be
+# labelled as a transitive dependency if every SET_PACKAGE_PROPERTIES
+# call for this package includes the TRANSITIVE_DEPENDENCY flag.
+#
#
#
# Example for setting the info for a package:
@@ -243,6 +250,7 @@
#=
# Copyright 2007-2009 Kitware, Inc.
+# Copyright 2014 Alex Merry d...@randomguy3.me.uk
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
@@ -274,7 +282,7 @@ function(SET_PACKAGE_PROPERTIES _name _props)
message(FATAL_ERROR PROPERTIES keyword is missing in
SET_PACKAGE_PROPERTIES() call.)
endif()
- set(options ) # none
+ set(options TRANSITIVE_DEPENDENCY)
set(oneValueArgs DESCRIPTION URL TYPE PURPOSE )
set(multiValueArgs ) # none
@@ -330,6 +338,12 @@ function(SET_PACKAGE_PROPERTIES _name _props)
set_property(GLOBAL PROPERTY _CMAKE_${_name}_TYPE ${_SPP_TYPE} )
endif()
+ if(_SPP_TRANSITIVE_DEPENDENCY)
+set_property(GLOBAL PROPERTY _CMAKE_${_name}_TRANSITIVE_DEPENDENCY TRUE)
+ else()
+set_property(GLOBAL PROPERTY _CMAKE_${_name}_TRANSITIVE_DEPENDENCY FALSE)
+ endif()
+
endfunction()
@@ -367,8 +381,9 @@ function(_FS_GET_FEATURE_SUMMARY _property _var
_includeQuiet)
if(${_type} STREQUAL ANY OR ${_type} STREQUAL ${_currentType})
- # check whether the current feature/package should be in the output
depending on whether it was QUIET or not
+ # check whether the current feature/package should be in the output
set(includeThisOne TRUE)
+
# skip QUIET packages, except if they are REQUIRED or
INCLUDE_QUIET_PACKAGES has been set
if((NOT ${_currentType} STREQUAL REQUIRED
Re: [cmake-developers] [PATCH] Do not output transitive dependencies in feature_summary()
On 03/02/14 19:27, Stephen Kelly wrote:
It's generally preferable to write an email and attach the patch.
Noted.
Alex Merry wrote:
+set_package_properties(${dep} PROPERTIES TRANSITIVE_DEPENDENCY)
I prefer not to create public API in set_package_properties for something
that doesn't need to be public. find_dependency() should be all the public
API needed.
I counter-propose the FeatureSummary-no-transitive topic which I just
pushed. What do you think?
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=a6971f651
I wasn't sure how changes to find_package for something like this would
go down. This seems like a better solution indeed.
Alex
--
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] [PATCH] Automoc documentation is misleading
The automoc documentation (http://www.cmake.org/cmake/help/v2.8.12/cmake.html#prop_tgt:AUTOMOC) states that all header files are considered for automoc, which is not true for any sensible definition of all header files. Only header files with certain names are considered: specifically, if you have a C++ file like file.cpp attached to the target, header files like file.h and file_p.h will be considered. If you have a header file like foo.h and the corresponding source file is, say, foo_win.cpp, automoc will never look at foo.h. The attached patch makes the documentation clear on this point. Alex Be clearer about which header files are considered for automoc The old documentation stated that all header files were considered, which was not true for any sensible definition of all header files. Only header files with certain names are considered. --- Help/manual/cmake-qt.7.rst | 6 +- Help/prop_tgt/AUTOMOC.rst | 5 +++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/Help/manual/cmake-qt.7.rst b/Help/manual/cmake-qt.7.rst index eff73b3..1040e28 100644 --- a/Help/manual/cmake-qt.7.rst +++ b/Help/manual/cmake-qt.7.rst @@ -58,7 +58,11 @@ AUTOMOC The :prop_tgt:`AUTOMOC` target property controls whether :manual:`cmake(1)` inspects the C++ files in the target to determine if they require ``moc`` to -be run, and to create rules to execute ``moc`` at the appropriate time. +be run, and to create rules to execute ``moc`` at the appropriate time. It +also inspects header files named ``file.hext`` and ``file.hext`` for +each C++ file ``file.cext``, where ``hext`` is a known C++ header file +extension like ``h`` or ``hxx``, and ``cext`` is the extension of the C++ +file. If a ``Q_OBJECT`` or ``Q_GADGET`` macro is found in a header file, ``moc`` will be run on the file. The result will be put into a file named according diff --git a/Help/prop_tgt/AUTOMOC.rst b/Help/prop_tgt/AUTOMOC.rst index 16094c7..e6385e1 100644 --- a/Help/prop_tgt/AUTOMOC.rst +++ b/Help/prop_tgt/AUTOMOC.rst @@ -12,8 +12,9 @@ statement like ``#include moc_foo.cpp`` is found, the ``Q_OBJECT`` class declaration is expected in the header, and ``moc`` is run on the header file. If an ``#include`` statement like ``#include foo.moc`` is found, then a ``Q_OBJECT`` is expected in the current source file and ``moc`` is run on -the file itself. Additionally, all header files are parsed for -``Q_OBJECT`` macros, and if found, ``moc`` is also executed on those files. +the file itself. Additionally, header files with the same base name (like +``foo.h``) or ``_p`` appended to the base name (like ``foo_p.h``) are parsed +for ``Q_OBJECT`` macros, and if found, ``moc`` is also executed on those files. The resulting moc files, which are not included as shown above in any of the source files are included in a generated ``targetname_automoc.cpp`` file, which is compiled as part of the -- 1.8.5.3 -- 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
