[cmake-developers] EXPORT_NAME-genex

[Stephen Kelly]

Brad King wrote:

> On 05/20/2013 09:48 AM, Stephen Kelly wrote:
>> Brad King wrote:
>> 
>>> What's so bad about the exported targets being called "boost_..."
>>> instead of "boost::..."?
>> 
>> A stronger indication that it is an imported target. boost::... can only
>> be an imported target, but boost_... could be an imported target, a
>> in-build target or a library.
> 
> Other than for error message generation, what does knowing whether a
> target is imported or not matter?  Abstracting that away has value too.
> See below.

Some other things I can think of is that an imported target can't be re-
exported, and its location property can be safely read (btw, I don't know if 
$<TARGET_FILE:tgt> reads the LOCATION for IMPORTED targets).

The difference can't be fully abstracted away. There are other differences 
in how they can be used. IMPORTED targets can't be used as the RHS in tll, 
for example. 

Also given this code:

 add_library(foo SHARED ...)

 add_library(imp SHARED IMPORTED)
 # ...
 set_property(TARGET imp 
   APPEND PROPERTY 
     LINK_INTERFACE_LIBRARIES foo) # Assuming imp has no configs

 add_library(bar ...)
 target_link_libraries(bar imp)

The foo target will not be a target dependency of bar. I discovered this 
last week while trying to make Qt static builds 'nice to use', which will 
involve creating a small static library to load the platform plugin (foo in 
the above example), which is close to what qmake does for static builds.

>> cost:
>>  * Projects may wish to have a different in-build name than exported
>>  name. * Anything else?
> 
> We commonly write test/example directories that work either in-build
> or as an outside project.  How to do this when the target name changes?
> It will need target aliases which adds even more complexity.

Yes, the solutions to that are either variables or target aliases. Whether 
target aliases are a good idea and are going to happen anyway can continue 
in the other thread though I think.

Thanks,

Steve.