[cmake-developers] Question about ALIAS targets

[Alex Merry]

On Monday, 5 June 2017 22:45:26 BST Stephen Kelly wrote:
> Brad King wrote:
> > Steve, is there any reason for the restriction other than not implementing
> > more use cases up front?
> 
> There may be more information in the mailing list archives, but as far as I
> remember, yes - we wanted to be conservative because we didn't know more
> use-cases. Additionally, we didn't know the impact of making the feature
> more unrestricted.

If you want to see an example use case, I found that c-ares were trying to ALIAS an 
IMPORTED library in their package config file to make it convenient for a downstream 
project to explicitly link against a static or shared library (if available), or link against "either" 
if they don't care:

https://github.com/c-ares/c-ares/blob/97f8b14c/c-ares-config.cmake.in

If c-ares is compiled with both static and shared options, it will produce c-ares::cares (shared) 
and c-ares::cares_static (static) exported targets. Otherwise, if only one of the static or shared 
options is specified, it will always just build and export a c-ares::cares target.

Obviously, the code won't work (and there is a pull request to fix it by using INTERFACE 
libraries at https://github.com/c-ares/c-ares/pull/108), and you may argue that this isn't the 
right solution to present downstreams with a "static vs shared vs don't care" choice, but I 
thought it might be interesting to show what developers are wanting to do with this.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170612/a17e37ba/attachment.html>