[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
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 neund...@kde.org wrote:
We could also not set pkg_FIND_REQUIRED_component, 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 pkg_FIND_REQUIRED_component 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 Thu, Mar 15, 2012 at 11:41 AM, Michael Hertling mhertl...@online.de wrote:
IMO, using solely pkg_FIND_REQUIRED_component 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 pkg_FOUND and pkg_comp_FOUND the meaning of
pkg_FIND_REQUIRED_comp and pkg_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
