[CMake] Debug vs Release "install" area

Looking for some advice. In order to make our Visual Studio debugging environment, as self-contained (and easy to use for the developers) as possible, we use developers must run an install. We also use the resulting release based Install for our packaging into our installer. We change the pre

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

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] Time Profile our CMake codes

We do the File IO because we need to store lists of various directories for other subprojects and packaging schemes to use. When we first developed the CMake codes the "set_property" function was not really well developed. I am wondering if using global property lists are a better way to go for

[CMake] Time Profile our CMake codes

Is there a way to "time profile" our cmake codes? We have noticed lately that running cmake on our project lately has taken a large uptick in time and we are trying to figure out where the newly added time is coming from. We do a lot of I/O writing temp files, comparing temp files to files that

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

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 wrote: > O

Re: [CMake] AUTOMOC with files on different folders

Thanks Attila, really appreciate your help. On Wed, May 11, 2016 at 11:23 PM, Attila Krasznahorkay < attila.krasznahor...@gmail.com> wrote: > Hi Tiago, > > Indeed, that page is quite a bit misleading. And it seems to be "liked" by > Google a lot, as most people come across it. (I also found it my

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

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

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 building the code for lib2 and lib

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

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 . PUB

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

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? regards, -- Patrick. -- Powered by w

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

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

On Thu, 12 May 2016 08:47:33 -0500 iosif neitzke wrote: > 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 > J

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

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 the *linking* of B behaves

Re: [CMake] CPack and PackageMaker

I think it is ok for the most of the use cases. But what I miss are the signing options: e.g: productbuild --component "FULLPATH_TO_OUTPUTDIR" /Applications --sign "DEVELOPER_CERTIFICATE" --product ".../Info.plist" MyPackage.pkg Best regards Roman > Am 05.04.2016 um 03:12 schrieb clin...@elemte