[cmake-developers] IMPORTED targets for some Find modules

[Stephen Kelly]

Philipp Moeller wrote:

> Stephen Kelly <steveire at gmail.com> writes:
> 
>> cmExportFileGenerator marks frameworks with a FRAMEWORK target property,
>> and Qt 5 emulates that. It could be done with these files too (I notice
>> in FindGLUT at least). I don't know if it has any effect on IMPORTED
>> targets, but it may in the future even if it does not currently.
> 
> That sounds like a good idea. Although I think that would make things
> very confusing: the IMPORTED_LOCATION would be the full path of the
> library, the INTERFACE_INCLUDE_DIRECTORIES would be the full path to the
> includes, but all of this is ignored as soon as -framework is used and
> the full path to the framework isn't specified (as far as my
> understanding of OSX goes).

I don't have great understanding of OSX either I'm afraid.

>> It looks like a good idea to add Boost::boost to the
>> INTERFACE_LINK_LIBRARIES of each component imported target, or to
>> similarly populate the INTERFACE_INCLUDE_DIRECTORIES of each component
>> imported target.
> 
> I contemplated that, but here I tried to anticipate Boost
> modularization. If we ever get specific include directories for each
> component we can break a lot of builds that wrongly relied on the fact
> that we brought in all of the Boost includes. If the includes are
> separated, this will be much easier to adapt to for users.

If you populate the INTERFACE_INCLUDE_DIRECTORIES on each component IMPORTED 
target, what can go wrong?

> 
>> I would say something similar about the GLUT imported targets, but it
>> seems that only GLUT::GLUT is documented, so presumably it is the only
>> one intended for users to use. Is it verified that the other libraries
>> are really interface dependencies and not runtime requirements? If they
>> are really interface usage requirements, where are the headers of the
>> other libraries located?
> 
> I don't understand what you mean by 'runtime requirements'. GLUT
> depends on either some X11 libraries or Cocoa for window creation, but
> doesn't expose the system APIs directly. You will still need to link
> against them.

You mean they must appear on the link line of your program? If so, then they 
are public dependencies of GLUT.

Or they have to be available only at runtime? If so then they are private 
dependencies of GLUT.

If they must appear on the link line of your program, then your program must 
use symbols from it, and then you need to have a definition of those symbols 
at compile time, which is usually provided in header files. 

Typically that happens if the headers of one library (Cocoa, in this case I 
think) are #included in the headers of another library (GLUT, in this case I 
think).

Is that the case? If not, then Cocoa is a private dependency.

> 
> I just went through the freeglut implementation and the external
> headers are only windows.h, gl.h, and glu.h. Those dependencies also
> missing in the original FindGLUT and this would be a worthwhile fix.

Then Cocoa etc are 'private dependencies', not 'public dependencies' and do 
not need to appear in the INTERFACE_LINK_LIBRARIES target property.

>> Is there a need to populate the IMPORTED_IMPLIB_<CONFIG> target
>> properties on Windows for any of the targets?
> 
> I don't have a Windows machine available right now, but I can try to
> figure this out later. Windows users tend to rely on Boost
> auto-linking though, which unfortunately doesn't interact very well with
> IMPORTED targets.

I don't know what auto-linking is and why that would not interact well with 
IMPORTED targets.

>> Others to consider for this compatibility requirement are the
>> Boost_COMPILER, Boost_NAMESPACE, Boost_THREADAPI etc.
> 
> Those changes would greatly enhance usability and I'll look into
> implementing them. For now I went with a minimal system that does not
> grant more safety than you would already get with the old-school
> variable style.

The problem is that if you implement the IMPORTED targets without using 
these compatibility features, adding them in the future would be a breaking 
change. CMake code might happen to work before you add them and break 
afterward.

Adding them now would introduce 'safe failure' early.

> First we need to get dependencies between Boost libraries figured out
> and then we should move on towards the full feature set.

Note also that the dependencies may have changed over time (and over boost 
releases). You could add specify the dependencies for only the most recent 
release, but even that is optional and can be done in the future.

Thanks,

Steve.