Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire wrote: > No you're not meant to specify paths yourself, you should just use > find_library. > Check how modules such as FindTIFF.cmake are implemented. > Please doc in CMake all the things I am "meant to" so as I can live

Re: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1

Hello I'm busy today. So I'll try tomorrow or the day after tomorrow. Regards Masaru. 2017年8月23日(水) 0:36 Brad King : > On 08/21/2017 05:56 PM, masaru tsuchiyama wrote: > >> https://gitlab.kitware.com/cmake/cmake/issues/17191 > > I think it is same as the issue. > > I

Re: [cmake-developers] C++11 all features available?

On Mon, Aug 21, 2017 at 4:32 PM, Sebastian Holtermann wrote: > Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie: > > On 08/21/2017 09:53 AM, Sebastian Holtermann wrote: > > > it looks like C++11 is now a requirement for CMake itself. > > > > Yes. We just merged this: >

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

No you're not meant to specify paths yourself, you should just use find_library. Check how modules such as FindTIFF.cmake are implemented. Le mar. 22 août 2017 à 19:05, Brian Davis a écrit : > > and provide future > > ​target_link_directories( >targ >INTERFACE >

Re: [CMake] CMake + Gradle for Android

Another reason to reduce the number of binary directories is that there are different ways of managing third party libraries. One in particular that we use is to clone a repository into the binary directory and build all third party libs in real time based on a toolchain file (Similar to the

Re: [CMake] target_link_libraries - private public interface rules

I think the documentation also fails to mention that link dependencies propagate even when "PRIVATE" is used, if the target is a static library. On 22 Aug 2017 4:40 pm, "Brad King" wrote: > On 08/22/2017 11:36 AM, Robert Maynard wrote: > > The `Transitive Usage

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

and provide future ​target_link_directories( targ INTERFACE debug ${TOP}/build/x64/Debug/Libraries/ optimized ${TOP}/build/x64/Release/Libraries/ ) with debug / optimized / general capability then targets could support multiple debug / release dirs even if CMake

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

Upon further reflection the abs paths for every lib is absolutely not defensible. 1) Pass only the short lib name to target_link_libraries 2) Add absolute path to future target_link_directories if you must Then it's one (1) long path on the command line string and not N long paths fore each lib

Re: [CMake] target_link_libraries - private public interface rules

On 08/22/2017 11:36 AM, Robert Maynard wrote: > The `Transitive Usage Requirements` section of the cmake-buildsystem > documentation quickly covers this idea but it could be elaborated on. > This might be a good place for a concrete example. Yes. Showing the transitive header case as an example

Re: [CMake] target_link_libraries - private public interface rules

The `Transitive Usage Requirements` section of the cmake-buildsystem documentation quickly covers this idea but it could be elaborated on. This might be a good place for a concrete example. Any thoughts Brad? On Tue, Aug 22, 2017 at 11:31 AM, Miller Henry wrote: > Is

Re: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1

On 08/21/2017 05:56 PM, masaru tsuchiyama wrote: >> https://gitlab.kitware.com/cmake/cmake/issues/17191 > I think it is same as the issue. > I use Japanese version of Win10 Pro. Thanks. Unfortunately I've not been able to reproduce it. See discussion in the issue. Since you have a local build

Re: [CMake] target_link_libraries - private public interface rules

Is that the right place to say things like If a header file contains #include Then OtherLibrary is probably candidate for PUBLIC, if the header contains the predeclaration class OtherLibraryClass; then OtherLibrary should be PRIVATE? I'm not against putting that content in

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

C comments On Tue, Aug 22, 2017 at 8:01 AM, Robert Maynard wrote: > Usage of link_directories is discouraged, and was part of the reason > why a target based option was not added. As the documentation for > link_directories states "Note that this command is rarely

Re: [CMake] target_link_libraries - private public interface rules

On Tue, Aug 22, 2017 at 10:45 AM, Robert Maynard wrote: > You could look at extending the official CMake documentation, > specifically the build system documentation ( > https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ). > > The documentation is all

Re: [CMake] target_link_libraries - private public interface rules

You could look at extending the official CMake documentation, specifically the build system documentation ( https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ). The documentation is all in restructure text and we accept documentation changes through our gitlab instance. cmake

[CMake] target_link_libraries - private public interface rules

I've been playing with the private/public/interface keyword to target_link_libraries. It seems to me that WHAT they do is well documented, but nobody has ever actually documented what they correct rules of WHEN/WHY you should use any of them. After a lot of misstarts I think I've started to

Re: [CMake] CMake + Gradle for Android

Sorry I forgot to answer your last set of questions: CommonLib is indeed 2 things: * A common (static or shared) library for native code (most of our CMake targets specify CommonLib as a link dependency) * A common library for Java code (we do specify this as a dependency for most java targets

Re: [CMake] CMake + Gradle for Android

Thanks to both of you for responding. First, to Jom's reply: The "x" part is what I was worried about. Each "path" resulting in a single binary dir. This is the part that I think could be optimized. I'll explain more on this later. Note also that this optimization might only benefit my specific

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

Usage of link_directories is discouraged, and was part of the reason why a target based option was not added. As the documentation for link_directories states "Note that this command is rarely necessary. Library locations returned by find_package() and find_library() are absolute paths. Pass these

[Cmake-commits] CMake branch, release, updated. v3.9.1-15-g02645aa

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 02645aa6aec748a1f3ea24715b3bd03465ae4835 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.9.1-549-g8a0ed37

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 8a0ed37f617347a6c7c37c50a5321f05d678fa76 (commit) via

Re: [cmake-developers] C++ IDE

I do not find it to be a joke, rather than being one of the best out there (if not THE best). I tried CLion just 2 weeks ago. It was a nice experience when it came to CMake, but it’s C++ IntelliSense capabilities seem to be lacking. (Truth be told, I did try with the experimental MSVC support,