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
[cmake-developers] depend problem on windows
So, I did a git branch switch to next and ran ninja on my build tree. It correctly re-ran cmake. But I found a link error building cmake-gui: CMakeLib.lib(cmLocalVisualStudio10Generator.cxx.obj) : error LNK2001: unresolved external symbol "public: virtual void __thiscall cmLocalVisualStudio7Generator::GetTargetObjectFileDirectories(class cmTarget *,class std::vectorstd::char_traits,class std::allocator >,class std::allocatorstd::char_traits,class std::allocator > > > &)" (?GetTargetObjectFileDirectories@cmLocalVisualStudio7Generator@@UAEXPAVcmTarget@@AAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z) bin\cmake-gui.exe : fatal error LNK1120: 1 unresolved externals LINK Pass 1 failed. with 2 I did a ninja -t clean, and then ninja and everything worked. So, it looks like some of the object files did not rebuild correctly after the branch switch. Same source tree worked with a gmake build tree, so there were no odd file time things going on. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013043]: IDL files do not supported if used NMake Makefiles generator
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13043 == Reported By:Vadim Sushchenko Assigned To: == Project:CMake Issue ID: 13043 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-03-15 09:16 EDT Last Modified: 2012-03-15 09:16 EDT == Summary:IDL files do not supported if used NMake Makefiles generator Description: IDL filles succefully supported by Visual Studio 2008 Generator but ignored by NMake Makefiles generator Steps to Reproduce: - Start VSMidl testcase - start cmake with NMake Makefiles generator - start nmake build failed. == Issue History Date ModifiedUsername FieldChange == 2012-03-15 09:16 Vadim SushchenkoNew Issue == -- 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
