Re: [cmake-developers] Package Config files with COMPONENTS
On Tuesday 20 March 2012, Brad King wrote: > On 3/19/2012 5:17 PM, Alexander Neundorf wrote: > > On Monday 19 March 2012, Brad King wrote: > >> Thanks. I rewrote the topic on the stage to clean up the history a > >> little and rebase it on top of the rewritten version of the other > >> find_package_set_FOUND_VariableInConfigFile topic. > > > > Hmm, I thought I had done that. > > I had deleted my local find_package_set_FOUND_VariableInConfigFile > > branch, then did git pull, then created a tracking branch from the > > remote branch, and branched away from this. > > Did you pull from origin or fetch from stage? The latter was necessary. Ok, that was it. > >> Please take a look at the new version of the topic. > > > > Is there a way to see what you changed ? > > Compare the old head to the new head of the branch: > > $ git fetch stage --prune > $ git diff e0694f64 stage/ImprovedCOMPONENTSSupportInFindPackage2 > > Note that because I rebased it on the modified version of the other > topic you will see those changes too. I pasted the relevant diff > below between your version and mine. > > -Brad > > > diff --git a/Source/cmFindPackageCommand.cxx > b/Source/cmFindPackageCommand.cxx index 05eb07d..ef16ce8 100644 > --- a/Source/cmFindPackageCommand.cxx > +++ b/Source/cmFindPackageCommand.cxx > @@ -99,15 +99,14 @@ void cmFindPackageCommand::GenerateDocumentation() > "The QUIET option disables messages if the package cannot be found. > " "The MODULE option disables the second signature documented below. " > "The REQUIRED option stops processing with an error message if the " - > "package cannot be found. " > +"package cannot be found." > +"\n" > "A package-specific list of required components may be listed after > the COMPONENTS option or directly after the REQUIRED option. " > -"A package should only be considered found if all of the listed " > -"components have been found. " > -"Additional package-specific optional components may be listed after > the " > -"OPTIONAL_COMPONENTS option. As opposed to the COMPONENTS option, the" > -"result for those components does not influence whether the package as" > -"a whole is considered to be found. " > +"Additional optional components may be listed after OPTIONAL_COMPONENTS > +"Available components and their influence on whether a package is " > +"considered to be found are defined by the target package." > +"\n" I would prefer if this documentation would recommend how COMPONENTS and OPTIONAL_COMPONENTS should be handled. Ok, this is done in readme.txt, but I would prefer to have it here too. But I don't have a strong opinion on this. 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
Re: [cmake-developers] Package Config files with COMPONENTS
On 3/19/2012 5:17 PM, Alexander Neundorf wrote:
On Monday 19 March 2012, Brad King wrote:
Thanks. I rewrote the topic on the stage to clean up the history a little
and rebase it on top of the rewritten version of the other
find_package_set_FOUND_VariableInConfigFile topic.
Hmm, I thought I had done that.
I had deleted my local find_package_set_FOUND_VariableInConfigFile branch,
then did git pull, then created a tracking branch from the remote branch, and
branched away from this.
Did you pull from origin or fetch from stage? The latter was necessary.
Please take a look at the new version of the topic.
Is there a way to see what you changed ?
Compare the old head to the new head of the branch:
$ git fetch stage --prune
$ git diff e0694f64 stage/ImprovedCOMPONENTSSupportInFindPackage2
Note that because I rebased it on the modified version of the other
topic you will see those changes too. I pasted the relevant diff
below between your version and mine.
-Brad
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index 05eb07d..ef16ce8 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -99,15 +99,14 @@ void cmFindPackageCommand::GenerateDocumentation()
"The QUIET option disables messages if the package cannot be found. "
"The MODULE option disables the second signature documented below. "
"The REQUIRED option stops processing with an error message if the "
-"package cannot be found. "
+"package cannot be found."
+"\n"
"A package-specific list of required components may be listed after the "
"COMPONENTS option or directly after the REQUIRED option. "
-"A package should only be considered found if all of the listed "
-"components have been found. "
-"Additional package-specific optional components may be listed after the "
-"OPTIONAL_COMPONENTS option. As opposed to the COMPONENTS option, the "
-"result for those components does not influence whether the package as a "
-"whole is considered to be found. "
+"Additional optional components may be listed after OPTIONAL_COMPONENTS. "
+"Available components and their influence on whether a package is "
+"considered to be found are defined by the target package."
+"\n"
"The [version] argument requests a version with which the package found "
"should be compatible (format is major[.minor[.patch[.tweak]]]). "
"The EXACT option requests that the version be matched exactly. "
@@ -612,18 +611,14 @@ bool cmFindPackageCommand
std::set_intersection(requiredComponents.begin(), requiredComponents.end(),
optionalComponents.begin(), optionalComponents.end(),
std::back_inserter(doubledComponents));
-
- if(doubledComponents.size() > 0)
+ if(!doubledComponents.empty())
{
-
cmOStringStream e;
-e << "called with the following components used for both COMPONENTS and "
- "OPTIONAL_COMPONENTS: ";
+e << "called with components that are both required and optional:\n";
for(unsigned int i=0; iSetError(e.str().c_str());
return false;
}
--
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] Package Config files with COMPONENTS
On Monday 19 March 2012, Brad King wrote: > On 3/18/2012 4:41 PM, Alexander Neundorf wrote: > > This is now in the ImprovedCOMPONENTSSupportInFindPackage2 branch on > > stage. > > > > It adds an OPTIONAL_COMPONENTS option to find_package(). > > It adds an option HANDLE_COMPONENTS to FPHSA(), so FPHSA() checks whether > > all requested required components have been found (doing this by default > > might break existing find-modules). > > It adds a macro check_required_components() to @PACKAGE_INIT@, configured > > using configure_package_config_file() > > > > It also adds documentation and testing. > > Thanks. I rewrote the topic on the stage to clean up the history a little > and rebase it on top of the rewritten version of the other > find_package_set_FOUND_VariableInConfigFile topic. Hmm, I thought I had done that. I had deleted my local find_package_set_FOUND_VariableInConfigFile branch, then did git pull, then created a tracking branch from the remote branch, and branched away from this. > I tweaked the documentation of component support in find_package to make it > clear that each package is responsible for dealing with components, just as > is already stated for version support. I also adjusted the formatting of > the required+optional component error message and added a test for it. > > Please take a look at the new version of the topic. Is there a way to see what you changed ? Looking at the commits I don't notice differences to what I had. 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
Re: [cmake-developers] Package Config files with COMPONENTS
On 3/18/2012 4:41 PM, Alexander Neundorf wrote: This is now in the ImprovedCOMPONENTSSupportInFindPackage2 branch on stage. It adds an OPTIONAL_COMPONENTS option to find_package(). It adds an option HANDLE_COMPONENTS to FPHSA(), so FPHSA() checks whether all requested required components have been found (doing this by default might break existing find-modules). It adds a macro check_required_components() to @PACKAGE_INIT@, configured using configure_package_config_file() It also adds documentation and testing. Thanks. I rewrote the topic on the stage to clean up the history a little and rebase it on top of the rewritten version of the other find_package_set_FOUND_VariableInConfigFile topic. I tweaked the documentation of component support in find_package to make it clear that each package is responsible for dealing with components, just as is already stated for version support. I also adjusted the formatting of the required+optional component error message and added a test for it. Please take a look at the new version of the topic. Listing a component both as COMPONENT and as OPTIONAL_COMPONENT is not allowed, cmake errors out then (3f9acd827da99ca581). I'm not sure this is good, maybe this list is created programmatically using dependent components, so maybe both a required and an optional component require and additional component, which is then maybe handed down to a find_package(NO_MODULE) call. Then we would have duplicated entries. If projects use such complex logic to choose the list of components then it is their responsibility to filter them to avoid duplicates. The list(REMOVE_ITEM) command can easily clean up duplicates. -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] Package Config files with COMPONENTS
On Tuesday 13 March 2012, Brad King wrote: > On 3/13/2012 5:10 PM, Alexander Neundorf wrote: > > Regarding the error: I think (didn't check) right now cmake doesn't > > complain if I list a component multiple times: > > > > find_package(Foo COMPONENTS bar blub bar) > > I don't think it does. > > > If it doesn't, then I'd say > > > > find_package(Foo COMPONENTS bar blub OPTIONAL_COMPONENTS bar) > > > > maybe also should not lead to an error. > > It is a new option so we can have new behavior ;) > > It can simply be an error to be in BOTH but not to repeat in one > or the other. > > -Brad This is now in the ImprovedCOMPONENTSSupportInFindPackage2 branch on stage. It adds an OPTIONAL_COMPONENTS option to find_package(). It adds an option HANDLE_COMPONENTS to FPHSA(), so FPHSA() checks whether all requested required components have been found (doing this by default might break existing find-modules). It adds a macro check_required_components() to @PACKAGE_INIT@, configured using configure_package_config_file() It also adds documentation and testing. Listing a component both as COMPONENT and as OPTIONAL_COMPONENT is not allowed, cmake errors out then (3f9acd827da99ca581). I'm not sure this is good, maybe this list is created programmatically using dependent components, so maybe both a required and an optional component require and additional component, which is then maybe handed down to a find_package(NO_MODULE) call. Then we would have duplicated entries. I'd prefer "required overrides optional". Please review. 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
Re: [cmake-developers] Package Config files with COMPONENTS
On Thu, Mar 15, 2012 at 11:41 AM, Michael Hertling wrote:
> IMO, using solely _FIND_REQUIRED_ to indicate if
> a requested component is mandatory or optional is not sufficient.
> Consider the following use case:
>
> FIND_PACKAGE(Foo COMPONENTS X OPTIONAL_COMPONENTS Y)
>
> Suppose both X and Y do require a component A. AFAICS, this is a
> completely regular case and provides for a component that should
> conceptually be considered mandatory *and* optional.
>
> In {FindFoo,FooConfig}.cmake, it has proven to be very convenient
> to add such prerequisite components to Foo_FIND_COMPONENTS at the
> beginning in order to process all components in a unique manner
> later on. Which value should one set Foo_FIND_REQUIRED_A to?
Use unset(). The other values are set by find_package to tell the
find module or package config file what the caller wants. Since the
user didn't specify an explicit preference for A then use the fact
that the value is not set to know that. The find_package command
doesn't pay attention to these variables as output so I couldn't care
less how a find module or package configuration file messes with them
internally for its own logic.
Unlike _FOUND and __FOUND the meaning of
_FIND_REQUIRED_ and _FIND_COMPONENTS are defined by
find_package rather than the individual package. This is a place
where a strict convention should be used. It should be well defined
what a given call to find_package is requesting from the package. The
design on which Alex and I settled achieves that.
> Instead, I'd suggest not to touch the value of Foo_FIND_REQUIRED_*
> but to add a further variable like Foo_FIND_OPTIONAL_*, as it is
> already done in 1a157e7. Then, just accept it if both variables
> are TRUE and leave it to {FindFoo,FooConfig}.cmake how to handle
> this case, i.e. bail out, prefer REQUIRED to OPTIONAL or whatever.
Introducing more variables will just lead to more state combinations
that need to be defined and understood by all parties on a per-package
basis. It is much simpler to say that a component cannot be both
required and optional.
-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] Package Config files with COMPONENTS
On 03/13/2012 09:55 PM, Brad King wrote:
> On Tue, Mar 13, 2012 at 4:43 PM, Alexander Neundorf wrote:
>> We could also not set _FIND_REQUIRED_, or set it to "0"
>> (which
>> would mean it is not required).
>
> Even better. One can loop over the_FIND_COMPONENTS list and then test
> the variable to see if it is really required or not.
>
>> Are there any compatibility issue to take into account ?
>> Until now, there never was a OPTIONAL_COMPONENT, so every call to
>> find_package(COMPONENTS ...) will work as before.
>
> I don't think there is a compatibility concern. A loop like the above
> would just consider every component required when the package is
> loaded by an older project that does not use the new keyword.
>
>> If somebody adds a OPTIONAL_COMPONENTS, this will add component entries to
>> the
>> FIND_COMPONENTS variable which have now _FIND_REQUIRED_ set to 0.
>> The Find-module or Config-file may not be prepared to handle this.
>
> I do not think that is a problem. The calling project should only use
> this option if the package to be found documents that it supports
> optional components. This is the same as passing only components
> documented by the package as known.
>
>> What is actually the purpose of the _FIND_REQUIRED_ variable ?
>> It currently doesn't add any information compared to the list
>> _FIND_COMPONENTS. Are you aware of any uses of this variable ?
>
> _FIND_REQUIRED_ came first. The entire feature was first added here:
>
> http://www.cmake.org/Bug/view.php?id=2771
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f625bea
>
> The _FIND_COMPONENTS list was added later because it is more convenient.
>
>> The argument parsing in cmFindPackage still has to decide what to do if a
>> component appears multiple times.
>> Error out ?
>> REQUIRED always has priority over OPTIONAL ?
>> Last one wins ?
>
> I think error is best. It's better to be explicit so authors do not
> assume ether way.
IMO, using solely _FIND_REQUIRED_ to indicate if
a requested component is mandatory or optional is not sufficient.
Consider the following use case:
FIND_PACKAGE(Foo COMPONENTS X OPTIONAL_COMPONENTS Y)
Suppose both X and Y do require a component A. AFAICS, this is a
completely regular case and provides for a component that should
conceptually be considered mandatory *and* optional.
In {FindFoo,FooConfig}.cmake, it has proven to be very convenient
to add such prerequisite components to Foo_FIND_COMPONENTS at the
beginning in order to process all components in a unique manner
later on. Which value should one set Foo_FIND_REQUIRED_A to?
Instead, I'd suggest not to touch the value of Foo_FIND_REQUIRED_*
but to add a further variable like Foo_FIND_OPTIONAL_*, as it is
already done in 1a157e7. Then, just accept it if both variables
are TRUE and leave it to {FindFoo,FooConfig}.cmake how to handle
this case, i.e. bail out, prefer REQUIRED to OPTIONAL or whatever.
IMO, this does neither imply inherent contradictions to be handled
by FIND_PACKAGE() nor constrain {FindFoo,FooConfig}.cmake's freedom
to process components in any suitable way. Finally, one could simply
allow arbitrary duplicates after COMPONENTS and OPTIONAL_COMPONENTS.
Note that this does not affect the question whether there should be
a sole comprehensive Foo_FIND_COMPONENTS variable or an additional
Foo_FIND_OPTIONAL_COMPONENTS one.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Package Config files with COMPONENTS
On 03/13/2012 06:30 PM, Brad King wrote:
> On 3/13/2012 1:12 PM, Alexander Neundorf wrote:
>> Setting CMP0018 to new would mean that the project supports only those
>> component-aware packages which follow that new convention.
>
> Yes, that cannot be a requirement to use
>
>cmake_minimum_required(VERSION 2.8.8)
>
> or whatever version of CMake introduces the policy as that would set
> it to NEW implicitly. We cannot make this a special case because then
> it would simply not be a policy. It introduces a requirement on the
> CMake version-awareness of a project's dependencies instead of just
> the project.
>
> > Some users/developers would prefer if there was a more strict definition of
> > how the COMPONENTS arguments should be handled.
>
> My proposal only requires the small change to CMake already under
> discussion and makes it possible for projects to provide package
> configuration files that handle components in a nice way. It also
> does not preclude the possibility of a future convention. However,
> any "strict definition" of behavior would *force* every project to
> adapt to it even if it doesn't make sense just because it made
> sense for a few *other* projects.
A further point why Foo_FOUND shouldn't be set by FIND_PACKAGE()
based on the Foo_*_FOUND variables of the mandatory components:
In {FindFoo,FooConfig}.cmake, I use to remove each component from
Foo_FIND_COMPONENTS once it has been processed, so at the end, the
remaining components are the unknown ones. This is quite handy and
makes it easy to provide Foo_*_FOUND==FALSE for the latters.
Even making Foo_FIND_COMPONENTS read-only is not a suitable solution:
IIRC, there is a consensus that {FindFoo,FooConfig}.cmake is expected
to search prerequisite but unrequested components by itself, and such
an unrequested prerequisite is expected to determine Foo_FOUND along
with the other mandatory components. A r/o Foo_FIND_COMPONENTS tends
to be incomplete in this regard.
The conclusion is that Foo_FIND_COMPONENTS is not guaranteed - at
no time - to hold all components intended to determine Foo_FOUND,
so an automatism like the one in 796ad77 is too short-sighted, IMO.
Instead, I'd agree that it should really be left to FooConfig.cmake
completely which value is assigned to Foo_FOUND in the end - unless
FooConfig.cmake doesn't do this or cannot be loaded. There might be
arbitrary findings the author of FooConfig.cmake wants to consider
for this purpose.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Package Config files with COMPONENTS
On 3/13/2012 5:10 PM, Alexander Neundorf wrote: Regarding the error: I think (didn't check) right now cmake doesn't complain if I list a component multiple times: find_package(Foo COMPONENTS bar blub bar) I don't think it does. If it doesn't, then I'd say find_package(Foo COMPONENTS bar blub OPTIONAL_COMPONENTS bar) maybe also should not lead to an error. It is a new option so we can have new behavior ;) It can simply be an error to be in BOTH but not to repeat in one or the other. -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] Package Config files with COMPONENTS
On Tuesday 13 March 2012, Brad King wrote: ... > > The argument parsing in cmFindPackage still has to decide what to do if a > > component appears multiple times. > > Error out ? > > REQUIRED always has priority over OPTIONAL ? > > Last one wins ? > > I think error is best. It's better to be explicit so authors do not > assume ether way. Ok, I'll work on it in the next days. Regarding the error: I think (didn't check) right now cmake doesn't complain if I list a component multiple times: find_package(Foo COMPONENTS bar blub bar) If it doesn't, then I'd say find_package(Foo COMPONENTS bar blub OPTIONAL_COMPONENTS bar) maybe also should not lead to an error. 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
Re: [cmake-developers] Package Config files with COMPONENTS
On Tue, Mar 13, 2012 at 4:43 PM, Alexander Neundorf wrote: > We could also not set _FIND_REQUIRED_, or set it to "0" (which > would mean it is not required). Even better. One can loop over the_FIND_COMPONENTS list and then test the variable to see if it is really required or not. > Are there any compatibility issue to take into account ? > Until now, there never was a OPTIONAL_COMPONENT, so every call to > find_package(COMPONENTS ...) will work as before. I don't think there is a compatibility concern. A loop like the above would just consider every component required when the package is loaded by an older project that does not use the new keyword. > If somebody adds a OPTIONAL_COMPONENTS, this will add component entries to the > FIND_COMPONENTS variable which have now _FIND_REQUIRED_ set to 0. > The Find-module or Config-file may not be prepared to handle this. I do not think that is a problem. The calling project should only use this option if the package to be found documents that it supports optional components. This is the same as passing only components documented by the package as known. > What is actually the purpose of the _FIND_REQUIRED_ variable ? > It currently doesn't add any information compared to the list > _FIND_COMPONENTS. Are you aware of any uses of this variable ? _FIND_REQUIRED_ came first. The entire feature was first added here: http://www.cmake.org/Bug/view.php?id=2771 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f625bea The _FIND_COMPONENTS list was added later because it is more convenient. > The argument parsing in cmFindPackage still has to decide what to do if a > component appears multiple times. > Error out ? > REQUIRED always has priority over OPTIONAL ? > Last one wins ? I think error is best. It's better to be explicit so authors do not assume ether way. -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] Package Config files with COMPONENTS
On Tuesday 13 March 2012, Brad King wrote:
> On 3/13/2012 3:25 PM, Alexander Neundorf wrote:
> > How about this:
> > * no policy
> > * new argument find_package( OPTIONAL_COMPONENTS), so we get two sets of
> > components
> > * the components are still ignored by find_package() for setting
> > Foo_FOUND * I add some code to FPHSA so it handled COMPONENTS and
> > REQUIRED_COMPONENTS as done in my branch (i.e. COMPONENTS are required,
> > OPTIONAL_COMPONENTS not) * I maybe add something to @PACKAGE_INIT@ to
> > help Config files handle components as recommended
> >
> > This way we could recommend to handle components in some way, and make it
> > easy for developers to follow the recommendation.
>
> Sounds good!
>
> Rather than two separate lists of components perhaps the
>
> _FIND_REQUIRED_
>
> variables could have the value "OPTIONAL" instead of "1" when a
> given component is optional.
Looks a bit strange IMO.
Both "OPTIONAL" and "1" evaluate to true.
And the value of e.g. Foo_FIND_REQUIRED_Comp would be "OPTIONAL", which kind
of conflicts with the "REQUIRED" in the name of the variable.
We could also not set _FIND_REQUIRED_, or set it to "0" (which
would mean it is not required).
Are there any compatibility issue to take into account ?
Until now, there never was a OPTIONAL_COMPONENT, so every call to
find_package(COMPONENTS ...) will work as before.
If somebody adds a OPTIONAL_COMPONENTS, this will add component entries to the
FIND_COMPONENTS variable which have now _FIND_REQUIRED_ set to 0.
The Find-module or Config-file may not be prepared to handle this.
What is actually the purpose of the _FIND_REQUIRED_ variable ?
It currently doesn't add any information compared to the list
_FIND_COMPONENTS. Are you aware of any uses of this variable ?
> This will probably simplify code
> dealing with components because it needs to loop over only one
> list
Hmm, maybe.
foreach(comp ${Foo_FIND_COMPONENTS})
vs.
foreach(comp ${Foo_FIND_COMPONENTS} ${Foo_FIND_OPTIONAL_COMPONENTS})
> and won't have to worry about whether a component can appear
> in both lists.
The argument parsing in cmFindPackage still has to decide what to do if a
component appears multiple times.
Error out ?
REQUIRED always has priority over OPTIONAL ?
Last one wins ?
I'd probably go with the second option.
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
Re: [cmake-developers] Package Config files with COMPONENTS
Brad King wrote: > My proposal only requires the small change to CMake already under > discussion and makes it possible for projects to provide package > configuration files that handle components in a nice way. It also > does not preclude the possibility of a future convention. I've been collecting links to discussions about this (and requirements for the macro I posted about before). I'll try to turn them into a coherent wiki page of all of the ideas soon, so that we'll be able to pick out some parts of it that we can aim for in CMake 2.8.9 etc. 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] Package Config files with COMPONENTS
On 3/13/2012 3:25 PM, Alexander Neundorf wrote: How about this: * no policy * new argument find_package( OPTIONAL_COMPONENTS), so we get two sets of components * the components are still ignored by find_package() for setting Foo_FOUND * I add some code to FPHSA so it handled COMPONENTS and REQUIRED_COMPONENTS as done in my branch (i.e. COMPONENTS are required, OPTIONAL_COMPONENTS not) * I maybe add something to @PACKAGE_INIT@ to help Config files handle components as recommended This way we could recommend to handle components in some way, and make it easy for developers to follow the recommendation. Sounds good! Rather than two separate lists of components perhaps the _FIND_REQUIRED_ variables could have the value "OPTIONAL" instead of "1" when a given component is optional. This will probably simplify code dealing with components because it needs to loop over only one list and won't have to worry about whether a component can appear in both lists. Thanks, -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] Package Config files with COMPONENTS
On Tuesday 13 March 2012, Brad King wrote: > On 3/13/2012 1:12 PM, Alexander Neundorf wrote: > > Setting CMP0018 to new would mean that the project supports only those > > component-aware packages which follow that new convention. > > Yes, that cannot be a requirement to use > >cmake_minimum_required(VERSION 2.8.8) > > or whatever version of CMake introduces the policy as that would set > it to NEW implicitly. We cannot make this a special case because then > it would simply not be a policy. It introduces a requirement on the > CMake version-awareness of a project's dependencies instead of just > the project. > > > Some users/developers would prefer if there was a more strict definition > > of how the COMPONENTS arguments should be handled. > > My proposal only requires the small change to CMake already under > discussion and makes it possible for projects to provide package > configuration files that handle components in a nice way. It also > does not preclude the possibility of a future convention. However, > any "strict definition" of behavior would *force* every project to > adapt to it even if it doesn't make sense just because it made > sense for a few *other* projects. How about this: * no policy * new argument find_package( OPTIONAL_COMPONENTS), so we get two sets of components * the components are still ignored by find_package() for setting Foo_FOUND * I add some code to FPHSA so it handled COMPONENTS and REQUIRED_COMPONENTS as done in my branch (i.e. COMPONENTS are required, OPTIONAL_COMPONENTS not) * I maybe add something to @PACKAGE_INIT@ to help Config files handle components as recommended This way we could recommend to handle components in some way, and make it easy for developers to follow the recommendation. 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
Re: [cmake-developers] Package Config files with COMPONENTS
On 3/13/2012 1:12 PM, Alexander Neundorf wrote: Setting CMP0018 to new would mean that the project supports only those component-aware packages which follow that new convention. Yes, that cannot be a requirement to use cmake_minimum_required(VERSION 2.8.8) or whatever version of CMake introduces the policy as that would set it to NEW implicitly. We cannot make this a special case because then it would simply not be a policy. It introduces a requirement on the CMake version-awareness of a project's dependencies instead of just the project. > Some users/developers would prefer if there was a more strict definition of > how the COMPONENTS arguments should be handled. My proposal only requires the small change to CMake already under discussion and makes it possible for projects to provide package configuration files that handle components in a nice way. It also does not preclude the possibility of a future convention. However, any "strict definition" of behavior would *force* every project to adapt to it even if it doesn't make sense just because it made sense for a few *other* projects. -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] Package Config files with COMPONENTS
On Tuesday 13 March 2012, Brad King wrote: > On 3/10/2012 1:15 PM, Alexander Neundorf wrote: > > I pushed a branch ImprovedCOMPONENTSSupportInFindPackage to stage. > > > > It is not finished (documentation and an updated fphsa() are missing at > > least), but you may want to have a look at it. > > > > It adds > > * OPTIONAL_COMPONENTS > > Will this interact well when a Find module forwards with NO_MODULE? > > > * CMP0018: if a listed component is not found, Foo_FOUND is set to false > > in Config mode > > I do not think CMP0018 can work quite as we need. If a project sets > the behavior to NEW how does it know the package configuration file > it finds will be aware that it needs to set the Foo__FOUND > variables? That is not something that cmake_minimum_required(VERSION) > can know when it sets the policy to NEW. > > We don't know how packages out there interpret components. For some > it may just be a list which can always be satisfied. Others may > already provide a value equivalent to Foo__FOUND but with > a different name that makes more sense for their use case. Setting CMP0018 to new would mean that the project supports only those component-aware packages which follow that new convention. 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
Re: [cmake-developers] Package Config files with COMPONENTS
On Tuesday 13 March 2012, Brad King wrote: > On 3/10/2012 1:15 PM, Alexander Neundorf wrote: > > I pushed a branch ImprovedCOMPONENTSSupportInFindPackage to stage. > > > > It is not finished (documentation and an updated fphsa() are missing at > > least), but you may want to have a look at it. > > > > It adds > > * OPTIONAL_COMPONENTS > > Will this interact well when a Find module forwards with NO_MODULE? It should. This branch is currently only a first step, to see how it would look like. > > * CMP0018: if a listed component is not found, Foo_FOUND is set to false > > in Config mode > > I do not think CMP0018 can work quite as we need. If a project sets > the behavior to NEW how does it know the package configuration file > it finds will be aware that it needs to set the Foo__FOUND > variables? That is not something that cmake_minimum_required(VERSION) > can know when it sets the policy to NEW. > > We don't know how packages out there interpret components. For some > it may just be a list which can always be satisfied. Others may > already provide a value equivalent to Foo__FOUND but with > a different name that makes more sense for their use case. > > The relationship of _FOUND and 's components is specific to > each package. I think it should simply be up to the package config > file for the package to set _FOUND based on its ability to > satisfy the requested components in whatever sense is meaningful > for the given package. Some users/developers would prefer if there was a more strict definition of how the COMPONENTS arguments should be handled. > This will be possible after the topic > find_package_set_FOUND_VariableInConfigFile is done. Yes. That's why I did this small branch first and with as few changes in behaviour as possible. > I think OPTIONAL_COMPONENTS may be worthwhile but that is independent > from the proposed policy. Hmm, but without the policy change (set Foo_FOUND only TRUE if all requested COMPONENTS have been found), OPTIONAL_COMPONENTS does not really make a lot of sense, since both will then simply result in two different cmake variables Foo_FIND_OPTIONAL_COMPONENTS and Foo_FIND_COMPONENTS, and both lists are still handled the same way, i.e. ignored for setting Foo_FOUND. 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
Re: [cmake-developers] Package Config files with COMPONENTS
On 3/10/2012 1:15 PM, Alexander Neundorf wrote: I pushed a branch ImprovedCOMPONENTSSupportInFindPackage to stage. It is not finished (documentation and an updated fphsa() are missing at least), but you may want to have a look at it. It adds * OPTIONAL_COMPONENTS Will this interact well when a Find module forwards with NO_MODULE? * CMP0018: if a listed component is not found, Foo_FOUND is set to false in Config mode I do not think CMP0018 can work quite as we need. If a project sets the behavior to NEW how does it know the package configuration file it finds will be aware that it needs to set the Foo__FOUND variables? That is not something that cmake_minimum_required(VERSION) can know when it sets the policy to NEW. We don't know how packages out there interpret components. For some it may just be a list which can always be satisfied. Others may already provide a value equivalent to Foo__FOUND but with a different name that makes more sense for their use case. The relationship of _FOUND and 's components is specific to each package. I think it should simply be up to the package config file for the package to set _FOUND based on its ability to satisfy the requested components in whatever sense is meaningful for the given package. This will be possible after the topic find_package_set_FOUND_VariableInConfigFile is done. I think OPTIONAL_COMPONENTS may be worthwhile but that is independent from the proposed policy. -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
