[cmake-developers] IMPORTED targets for some Find modules

[Philipp Moeller]

Stephen Kelly <steveire at gmail.com> writes:

> Philipp Moeller wrote:

[...snipped...]

>> 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?

On a non-modularized build I will need to populate it with
Boost_INCLUDE_DIR as we don't do detection of different include
directories yet. This would allow users to accidentally use headers from
a different component. The way it is done now, users will be aware that
they bring in all includes and know what to change if they wish to use a
modular Boost.

>>> 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.

Not necessarily. Imagine:

foo.h:

    void f();

foo.cpp:
    #include <foo.h>
    #include <GL/gl.h>
    
    void f() { 
      glVertex2i(1, 2);
    }

If you build a library using foo.cpp it will contain the glVertex2i
symbol even though its headers wont include it. Likewise a consumer of
that library does not need to have the headers, but will need to link
against a library containing the symbol. This is exactly the case in
GLUT. Thus they need to be PUBLIC or INTERFACE dependencies.

> 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.

[...snipped...]