That's very nice; thanks!
--
Ivan Shapovalov / intelfx /
On 2016-08-18 at 15:29 +0200, Tamás Kenéz wrote:
> Ivan,
>
> >
> > But, if library `foo` is built as static, then its clients suddenly
> > become required to link to `bar` as well, and this information is
> > not
> > recorded anywhere!
>
Ah! When I do that, it also solves the include path bloat issue. No
longer does `client` know about the include directory of `bar`. Seems
it was a difference in minimum CMake version respecting old behavior.
In FooTargets.cmake, I see this line:
INTERFACE_LINK_LIBRARIES "\$"
Awesome. Of course, t
Ivan,
> But, if library `foo` is built as static, then its clients suddenly
> become required to link to `bar` as well, and this information is not
> recorded anywhere!
I changed the cmake_minimum_required version in your projects from 2.8 to
3.0 which fixed the issue.
(I tried it with cmake 3.6.
On 2016-08-17 at 05:19 -0500, Nicholas Braden wrote:
> Huh, this is weird. It seems to be an issue with the export/import
> mechanism. If you make a project where everything is in the same
> CMakeLists.txt and there is no install step, there is no include
> directory pollution. See my attached proj
On 2016-08-16 at 20:14 -0500, Nicholas Braden wrote:
> Ah, I misunderstood what you were asking about. It would be pretty
> weird if CMake didn't know that static libraries always need all
> their
> dependencies linked regardless of privacy, but I agree it should at
> least be mentioned somewhere.
Ah, I misunderstood what you were asking about. It would be pretty
weird if CMake didn't know that static libraries always need all their
dependencies linked regardless of privacy, but I agree it should at
least be mentioned somewhere. My bad.
As for include path bloat, I cannot replicate this in
TBH, I do not see the "PRIVATE dependencies are made PUBLIC for the
purposes of linking when the dependent is static library" there.
--
Ivan Shapovalov / intelfx /
On 2016-08-16 at 02:35 -0500, Nicholas Braden wrote:
> Yes, the behavior is documented in several places, the most prominent
> bein
Yes, the behavior is documented in several places, the most prominent
being here:
https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#transitive-usage-requirements
On Mon, Aug 15, 2016 at 9:22 PM, Ivan Shapovalov wrote:
> On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote:
>> A
On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote:
> As far as I know the PRIVATE
> keyword
> should have no effect on transitive linking when foo is static and we
> call:
>
> target_link_libraries(foo PRIVATE bar)
>
> Hope this helps.
Wow. I did not know that. Should've tested on sample proj
If you export you targets using
install(EXPORT ...)
then the foo static library should contain a dependency to bar in its
INTERFACE_LINK libraries. If bar is an imported target your config file
should use find_dependency so that the bar imported target is resolved by
consuming CMake based package
Hello,
So I'm trying to learn how to do CMake in a modern way. If I understand
correctly, the "modern way" is to use IMPORTED targets.
Preamble
I have a project which builds a library `foo`. This library can be
built as static or shared, depending on value of BUILD_SHARED_LIBS. My
CMake
11 matches
Mail list logo
