[cmake-developers] Target usage requirements and conventions

[Stephen Kelly]

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.