[Cmake-commits] CMake branch, master, updated. v3.11.1-806-gc698dbd

VERSION_MINOR 11) -set(CMake_VERSION_PATCH 20180515) +set(CMake_VERSION_PATCH 20180516) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] Forcing a target to be built if another target is built

Have you thought about not doing anything in the root CMakeLists for your testing directories but instead inside the active project you use add_subdirectory ( it supports relative paths to handle directories not physically nested inside it ). On Wed, May 9, 2018 at 8:56 AM Job Noorman

Re: [CMake] How to update librarian section of project properties for a visual studio project using cmake?

If you want an official CMake response, take it from Brad King himself: https://gitlab.kitware.com/cmake/cmake/issues/16931 His second comment is interesting, I haven't tried the path of trying to trick it into thinking it is an object file. That might be the way to go! -Caleb On Tue, May 15,

Re: [CMake] How to update librarian section of project properties for a visual studio project using cmake?

You are unfortunately out of luck here. CMake does not provide built in functionality to create "fat" static libs (multiple static libs combined). Visual Studio allows this quite easily but CMake does not. All static libs are considered transitive dependencies and get carried through to executable

[cmake-developers] How to handle dependencies of protobuf files ?

Hi, I stumbled upon a problem with protobuf files, I attached a testcase. There is a MyBase.proto, which is "imported" by Complex.proto. If MyBase.proto is modified, protoc is run again in MyBase.proto, but not on Complex.proto, although it should. You can have a look at the attached example.

[CMake] How to update librarian section of project properties for a visual studio project using cmake?

Hi, I am creating a static library which in turn depends on several other libraries. So on Windows in Visual studio for my master library I have updated Librarian section of project properties to add the other libraries as additional dependencies. If I update Librarian section manually then I am

Re: [CMake] target_link_libraries and Custom Properties

> I also wasn't able to find a way to get a list of targets a given target depends on, so that I could run through it and query each dependent target's custom property manually. This isn't currently possible. > The executable targets need to collect the shader files and headers of only the

Re: [CMake] include directories not found for object library

This is scheduled to be fixed in the next release by allowing OBJECT libraries to be used in target_link_libraries. On Tue, May 8, 2018 at 7:46 PM Miklos Espak wrote: > Hi, > > I have an abstract class that I want to compile into many applications. > Something like this: > >

[Cmake-commits] CMake branch, release, updated. v3.11.1-37-g29d20e2

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 29d20e2e0ce6a189e0e8fbfa2f7355f94749e390 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.11.1-805-g743f24b

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 743f24bac68010c0157dc0349958e09ed1784f5f (commit) via

[Cmake-commits] CMake branch, master, updated. v3.11.1-800-g6423419

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 64234199ae6a49575b347c8eea296ea3087641cf (commit) via

[Cmake-commits] CMake branch, release, updated. v3.11.1-34-g813bcc2

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 813bcc2997a5692e8d9e141cf12b662b8b4dfbac (commit) via

[Cmake-commits] CMake branch, master, updated. v3.11.1-795-gc299920

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 c29992078f2d8683228030f847948a902ac9173b (commit) via

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

On 05/15/2018 03:22 AM, Stephen Kelly wrote: > So, the answer for cmake might be that CMake can learn to extract that > stuff, but ignore certain cases like imports within ifdefs. We'd need to do the extraction from already-preprocessed sources. This is how Fortran+Ninja+CMake works.

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

David Blaikie wrote: >> Nope, scratch that ^ I had thought that was the case, but talking more >> with Richard Smith it seems there's an expectation that modules will be >> somewhere between header and library granularity (obviously some small >> libraries today have one or only a few headers,

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

Brad King wrote: > On 05/07/2018 12:01 PM, Stephen Kelly wrote: >> Hopefully Brad or someone else can provide other input from research >> already done. > > I'm not particularly familiar with what compiler writers or the modules > standard specification expects build systems to do w.r.t modules.