On Wed, May 2, 2012 at 1:18 PM, Alexander Neundorf <neund...@kde.org> wrote:
> On Wednesday 02 May 2012, Stephen Kelly wrote:
>> Brad King wrote:
> ...
>> > to mean find-if-necessary. Then arguments after "Bar" would be
>> > passed to the implied find_package for version and all the other
>> > options. Either Module mode or Config mode could detect whether
>> > there is enough information to define the Bar package, and then
>> > do so. See below.
>> >
>> > This brings up a fundamental question for this design discussion.
>> > Are usage requirements associated with packages, with targets, or
>> > with either/both?
>>
>> Both, I think. They are associated with targets because properties on
>> targets are what needs to be propagated as required for usage, and because
>> targets will get usage requirements from other targets.
>>
>> They are associated with packages for compatibility with packages which do
>> not create exported targets, but which do have conventional prefixes on
>> variables.
>
> Going one step back: why is the package mode then necessary at all ?
> If it is for packages which don't create imported targets, can't the
> VARIABLE_PREFIX mode be used then ?
>
>> >>> We will likely need to make packages something first-class on the
>> >>> C++ side. If find_package(Bar) detects that the files it loaded
>> >>> define sufficient information for a package it should construct a
>> >>> C++ object to represent the package. This event should establish
>> >>> the package. A loose sequence of variable set()s is not explicit
>> >>> enough.
>> >>
>> >> Right.
>> >
>> > How might find_package detect/define a first-class package object?
>> > Just look for the right variables? Perhaps we could add an (optional)
>> >
>> > explicit package declaration:
>> > cmake_package(Bar LIBRARIES ... DEFINITIONS ...)
>> >
>> > that can be either in the Find module or in the package configuration
>> > file. This would allow more detailed information to be set.
>>
>> Maybe. Where would this get us that convention in the right variables would
>> not?
>>
>> I can imagine someone looking at that and thinking that that's the way to
>> notify users of my package/config file how to use it, and disregard the
>> actual variable name conventions:
>>
>> FooConfig.cmake:
>>
>> set(THE_FOO_LIBRARIES foo1 foo2)
>>
>> cmake_package(Foo LIBRARIES ${THE_FOO_LIBRARIES})
>>
>> Then again, cmake_package could also ensure that the correct conventional
>> variables are set by actually setting Foo_LIBRARIES to be the contents of
>> THE_FOO_LIBRARIES in that case, ensuring the possibility of using the
>> variables conventionally.
>>
>> That also opens up the question of whether it should overwrite
>> Foo_LIBRARIES if it already exists, or warn about that.
>>
>> I also think the 'Foo' would be redundant. It should be this to avoid
>> mistakes:
>>
>> cmake_package(LIBRARIES ${THE_FOO_LIBRARIES})
>>
>> CMake already knows the name of the package, right?
>
> Isn't this getting a bit too much of new concepts ?
> I mean, the semantics of target_use_package() with imported or in-project
> targets are quite clear.
> Isn't everything else not maybe only added complexity for little benefit ?
>
> 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
I agree with Alex here -- let's start simple and add from there.
target_use_package should make a target use a package. To me, that
means starting with the basics:
- automatically add all the right include directories
- automatically add any required definitions
- automatically add any required compiler flags
- automatically link to the right libraries
- do so recursively for any additional packages that the package itself uses
- avoid cycles when recursing
- detect incompatibilities and inconsistencies and warn about them
early if possible
2 cents,
David
--
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
