[cmake-developers] IMPORTED targets for some Find modules

[Philipp Moeller]

Stephen Kelly <steveire at gmail.com> writes:

> Philipp Moeller wrote:
>
>> Stephen Kelly <steveire at gmail.com> writes:
>
>>> 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.
>
> Please correct me where I go wrong here:
>
> 1) All boost releases (including the next one) are monolithic
> 2) So there is only one Boost_INCLUDE_DIR
> 3) So, different components don't have different usage-include-directories
>
> Are you talking about a scenario where there are multiple different Boost 
> installations found at different prefixes? 
>
> Or what do you mean about 'accidentally using 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.
>
>  add_executable(foo main.cpp)
>  target_link_libraries(foo Boost::thread)
>
> should 'just work' without having to add another target to provide the 
> include dir.
>
> I don't understand what you're saying or arguing for here, but if Brad does 
> I guess he'll merge it :).

I was talking about a modularized Boost which doesn't use CMake. As
long as stuff is monolithic this will bring in all include directories
and the build will be harder to modularize. The way it is done now a
user would need:

    add_executable(foo main.cpp)
    target_link_libraries(foo Boost::boost Boost::thread)

and be aware that this just brought in all includes. If she ever
switches to a modularized Boost this becomes:

    add_executable(foo main.cpp)
    target_link_libraries(foo Boost::thread)

Maybe my thinking is too complex here and your example has merit. Some
stuff should just work.

>> 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. 
>
> Ah, I guess we're talking about static libraries here.