Hello,
Can someone confirm please if this is a bug and whether I should file a bug
report?
Also, the "PRIVATE" workaround doesn't suit me (because it breaks
transitivity of includes). Is there any other workaround I can use? I
assume reverting to static libraries is the best thing to do in the
me
Hello,
PRIVATE works, but I don't understand why (the only difference between the
two examples is using a subdirectory).
Using ${CMAKE_CURRENT_SOURCE_DIR} does not work.
Thanks,
-- Giovanni
On Fri, Dec 9, 2016 at 4:17 PM, Chuck Atkins
wrote:
> Hi Giovanni,
> Does it work if you add lib1 as a
Hi Giovanni,
Does it work if you add lib1 as a private dependency of lib2? i.e.:
target_link_libraries(lib2 PRIVATE lib1)
Also, it shouldn't matter but what about in your original example if you
use the full path to the source file instead while still keeping the public
link dependency? i.e.:
ad
Hi,
Apologies, the problem wasn't properly minimised because I had some trouble
wrapping my head around it. Here's two complete examples which I hope can
explain the problem better this time.
1) This works:
[CMakeLists.txt]
cmake_minimum_required(VERSION 3.6)
project(Test)
add_librar
Giovanni Funchal wrote:
> Hi,
>
> The help page [1] mentions that:
>
>> Although object libraries may not be named directly in calls to the
>> target_link_libraries() command, they can be “linked” indirectly by
>> using an Interface Library whose INTERFACE_SOURCES target property
>> is set to na
Hi,
The help page [1] mentions that:
> Although object libraries may not be named directly in calls to the
> target_link_libraries() command, they can be “linked” indirectly by
> using an Interface Library whose INTERFACE_SOURCES target property
> is set to name $.
However, I was unable to get t
