Alexander Neundorf wrote:
> On Sunday 29 April 2012, Stephen Kelly wrote:
>> Hi there,
>>
>> The topic of 'target usage requirements' has come up several times. It's
>> something I'd like to work further towards in CMake 2.8.9.
>>
>> I have created a wiki page on the KDE wiki (there for my convenience
>> mostly) so that we can discuss the design, implementation and
>> implications.
>>
>> http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements
>>
>> Thanks for any comments,
>
> Some comments:
>
> You propose target_use_package(Foo Bar) to state that the target Foo
> should use the include dirs and libraries from Bar. I like the idea of
> having a separate command for that.
Yes, I think we have consensus on that.
> I do not like the idea that target_use_package() should automatically do a
> find_package() for several reasons.
> * find_package() has many options, in the end they would all have to be
> present there too
Not really. It's most common to invoke it with no arguments or with a
version check. The target_use_package(Foo) would only do a find_package(Foo)
of Foo_FOUND is not true. That would allow:
find_package(Foo ${COMPLEX_ARGS})
target_use_package(Bar Foo)
in cases where it's warranted. It probably would make sense and 'fit' for
target_use_package() to have versioning arguments though which it would pass
to find_package.
This avoids the 'double booking' problem[1], which I think might be real, so
I think it's a good idea to optimize the common case, but I won't be too
disappointed if it's not acceptable.
> * find_package() is an important part of the CMakeLists.txt, it should not
> be hidden
Well, both commands have 'package' in their name. It's reasonable to think
they're related.
> * wouldn't this fall back to a find_package() call with its associated
> error messages at cmake-time for every typo in the package name ?
I don't think I understand the question.
Yes, target_use_package(Bar oFo) would give errors from find_package, but
that's a typo anyway, so I would expect it to. It won't work unless fixed.
>
> Looking at other cmake commands, many of them now have two modes, an old
> one, where simply the options are listed without separating keywords:
> find_library(FOO_LIBRARY foo /opt/foo /usr/foo/lib)
> and a new, more powerful one with additional keywords:
> find_library(FOO_LIBRARY NAMES foo PATHS /opt/foo /usr/foo/lib)
>
> When adding a new command, we should start with the keyword-based variant,
> to avoid having two signatures in the future.
> This also makes the code more explicit about what it does, less guessing
> involved for readers:
>
> target_use_package(Foo IMPORTED_TARGETS Bar Blub)
> or
> target_use_package(Foo VIA_PREFIX Bar_Bat )
> or
> target_use_package(Foo PACKAGE Bar)
Yes.
>
> Doing it this way would also solve the problem that your prefix-based
> example:
>
> target_use_package(Foo ${Bar_Bat_LIBRARIES})
> "... Otherwise, the variables with the appropriate naming conventions (eg
> Bar_Bat_LIBRARIES Bar_Bat_INCLUDE_DIRS) are used."
>
> the target_use_package() implementation would get to see that value of
> ${Bar_Bat_LIBRARIES}, which might be
> "/usr/lib/libbat.so;/usr/lib/libbar.so", and wouldn't be able to find out
> about prefixes anymore.
Thanks for the feedback,
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
