[cmake-developers] EXPORT_NAME-genex

[Alexander Neundorf]

On Monday 20 May 2013, 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.
> 
> As we discussed in another thread, we can check for '::' to see if it is an
> imported target and error if that imported target is not available.
> 
> > VTK and ITK have worked that way for years.
> > It is simpler if the name inside the upstream build matches that in
> > the downstream consumers.
> 
> Why is that simpler?
> 
> By the same logic, is it simpler for the target name to match the output
> name? Should the OUTPUT_NAME property exist?

OUTPUT_NAME does make things more complicated when used, but sometimes it is 
necessary. In KDE this was the case when converting to cmake, and names of 
produced files were not allowed to change.
E.g. somewhere we had a library libkfoo.so and an executable kfoo. Both target 
names would be "kfoo" in cmake, so here via setting the OUTPUT_NAME it was 
possible to keep the name of the files on disk unchanged while having separate 
names for the two targets.

> > We had some recent discussion about encouraging the convention of
> > "namespace::" for imported targets, but perhaps we should reconsider

IMO encouraging/recommending this is good.
This is much strong less than producing an error if it is not used.

> > the value and cost.
> 
> value:
>  * We can assume that NS::foo is an imported target and error if not found

Since it was never forbidden and not even officially recommended to use "::" 
when exporting targets, I'm not sure the "::" should be used for the decision 
whether an error is generated or not.
Also, the "::" is only a strong indication, not more.
E.g. I can build the attached example using the ninja generator.

>  * Readers know that NS::foo is imported and tll(bar NS::foo) does more

Yes.

Those two are advantages of using a namespace when exporting targets. This can 
be done already right now.

And as I said already before, I would not recommend using imported target 
names directly.

How about extending readme.txt and recommend that Config.cmake files 
additionally to Foo_INCLUDE_DIRS and Foo_LIBRARIES also set Foo_TARGETS if 
they create imported targets ?

> cost:
>  * Projects may wish to have a different in-build name than exported name.

Why ?

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: colcol.tar.gz
Type: application/x-compressed-tar
Size: 398 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130520/42fa3d15/attachment-0002.bin>