Stephen Kelly <steve...@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...]
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
