[CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

[Craig Scott]

Patrick,

I suggest if you can reduce your problem down to a small, reproducible
example, then file a bug. I did a test just now with CMake 3.5.2 and
everything behaved as expected, including the header search path
propagation, so maybe there's something unusual in your project which a
simple case doesn't capture. Perhaps also try different generator types in
case that results in something different (unlikely, but since you see
different behaviour to me, give it a go).


On Fri, May 13, 2016 at 12:30 AM, iosif neitzke <
iosif.neitzke+cmake at gmail.com> wrote:

> I guess the key is static libraries don't exactly adhere to the rules
> of PUBLIC or PRIVATE, so you end up with a library that CMake passes
> along with a populated INTERFACE_INCLUDE_DIRECTORIES, and so exe1 uses
> it because it is there?  Not sure how it is supposed to work at this point.
>
> On Thu, May 12, 2016 at 9:26 AM, Patrick Boettcher
> <patrick.boettcher at posteo.de> wrote:
> > On Thu, 12 May 2016 09:20:10 -0500
> > iosif neitzke <iosif.neitzke+cmake at gmail.com> wrote:
> >
> >> I'm sorry, I'm not sure I understand.  In your example, there is
> >> target_link_libraries(lib3 PUBLIC lib1).  It looks like lib2 has
> >> target_link_libraries(lib2 PRIVATE lib1).
> >
> > Yes. That is correct.
> >
> > When building the code for lib2 and lib3 the include-path of lib1 is
> > provided (as expected).
> >
> > Then when building exe1 (links to lib2) and exe2 (links to lib3) the
> > lib1's include-path is present in both cases.
> >
> > Whereas it should not be present with exe1, at least that is my
> > understanding.
> >
> > --
> > Patrick.
>



-- 
Craig Scott
Melbourne, Australia
http://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160513/b610adb6/attachment.html>