Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2019-12-29 Thread Alan W. Irwin
On 2019-12-29 12:15+1100 Craig Scott wrote: This one has sat in my inbox for a long time - sorry I'm only getting to it now! No problem, and big thanks for replying late rather than taking the easier course of replying never. I haven't yet absorbed all of what you said, but I am sure your

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2019-12-28 Thread Craig Scott
This one has sat in my inbox for a long time - sorry I'm only getting to it now! On Wed, Sep 18, 2019 at 9:21 AM Alan W. Irwin wrote: > Hi Craig: > > It appears you pretty much made the definitive statement about > target_link_libraries (TLL) options at >

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2019-09-18 Thread Simon Richter
Hi, On Tue, Sep 17, 2019 at 04:21:36PM -0700, Alan W. Irwin wrote: > * It appears to me that if a CMake-based build system is configured > properly there is very little need for the PUBLIC option for TLL > because PRIVATE works well for shared libraries and the > PRIVATE-becomes-PUBLIC

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2019-09-17 Thread Alan W. Irwin
Hi Craig: It appears you pretty much made the definitive statement about target_link_libraries (TLL) options at . However, I have some further questions about this key section of your statement: "[...] when A links in B as PRIVATE, the

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-13 Thread Patrick Boettcher
On Fri, 13 May 2016 07:06:32 +1000 Craig Scott wrote: > 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

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread 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

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread iosif neitzke
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). http://public.kitware.com/pipermail/cmake/2016-May/063382.html On Thu, May 12, 2016 at 9:10 AM, Patrick Boettcher

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread iosif neitzke
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

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread Patrick Boettcher
On Thu, 12 May 2016 09:20:10 -0500 iosif neitzke 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

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread iosif neitzke
target_include_directories(lib1 INTERFACE /tmp) means /tmp is propagated with lib1, but not used to build lib1. "The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of .

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread Patrick Boettcher
On Thu, 12 May 2016 09:04:10 -0500 iosif neitzke wrote: > target_include_directories(lib1 INTERFACE /tmp) means /tmp is > propagated with lib1, but not used to build lib1. I know. Could you elaborate how this is related with lib3 PRIVATEly linking to lib1?

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread iosif neitzke
My reading of your examples: exe1 gets linked to lib2, and lib2/bin is included. exe1 probably won't link ultimately because lib2 may need symbols from lib1. Depends on the structure of the C code between lib2 and lib1. See John Lakos for further information on that. exe2 gets linked to lib3,

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-12 Thread Patrick Boettcher
On Wed, 11 May 2016 21:58:34 +1000 Craig Scott wrote: [..] > If you were paying careful attention, you would have noticed that > when A links in B as PRIVATE, the include directories of B never > propagate to something linking to A, but if A is a static library, > then

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-11 Thread iosif neitzke
> When A links in B as PRIVATE, it is saying that A uses B in its > implementation, but B is not used in any part of A's public API. > When A links in B as INTERFACE, it is saying that A does not use B in its > implementation, but B is used in A's public API. > When A links in B as PUBLIC, it is

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-11 Thread Craig Scott
Hopefully the explanation that follows helps clarify what PRIVATE, PUBLIC and INTERFACE mean and do. From my understanding of things, I think there may have been some subtle inaccuracies in some of the discussions so far, so hopefully the following is helpful and if I've got something wrong, then

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-11 Thread iosif neitzke
>> I *think* that these public/private rules behave a bit differently >> for static libraries than they do for shared ones. They do. Assuming main calls a() and b() defined in A_lib and B_lib respectively, for: add_library(A_lib STATIC a.c) add_library(B_lib STATIC b.c)

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-10 Thread Patrick Boettcher
On Tue, 10 May 2016 11:39:49 +0200 Attila Krasznahorkay wrote: > Hi Patrick, > > I *think* that these public/private rules behave a bit differently > for static libraries than they do for shared ones. > > But I have to admit, that based on this code I also

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-10 Thread Attila Krasznahorkay
Hi Patrick, I *think* that these public/private rules behave a bit differently for static libraries than they do for shared ones. But I have to admit, that based on this code I also would've guessed that -I/tmp would not show up in the build of exe1... I did manage to use public and private

[CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

2016-05-10 Thread Patrick Boettcher
Hi list, What is the differences between PRIVATE and PUBLIC when used with target_link_libraries? I read the help and understood that it works like in C++: PRIVATE will make everything which was PUBLIC before also PRIVATE if inherited privately. An example: add_library(lib1 INTERFACE)