[Cmake-commits] CMake branch, master, updated. v3.13.0-547-g049ca05

t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 63a1573..93aad21 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 13) -set(CMake_VERSION_PATCH 20181127) +set(CMake_VER

[CMake] Subdirectory can't find library made by another subdir

Hi everyone, I'm having a bug on CMake 3.12 (version and syntax). Here is my structure. RootFolder     CMakeLists.txt (C1)     library/         CMakeLists.txt (C2)     samples/         CMakeLists.txt (C3) In my C1, I add subdir library and samples. C2 builds a library target (LIB). My

Re: [CMake] Does CMake support the --question option for GNU Makefiles?

Thanks for the quick response it makes more sense now. Looking at our CMake files, I see now that all our targets are indeed PHONY, because we use *add_custom_target *to create those targets. So no matter what they are always considered out of date. For now I'll have to assume that whoever wrote

Re: [CMake] Can an option enforce a default, even if cache is present?

On Tue, Nov 27, 2018 at 3:15 PM Mario Emmenlauer wrote: > > On 27.11.18 17:13, Eric Noulard wrote: > > Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer > > a écrit : > > Dear all, > > > > I've just discovered that option() behaves differently than I > >

Re: [CMake] Can an option enforce a default, even if cache is present?

On 27.11.18 17:13, Eric Noulard wrote: Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer > a écrit : Dear all, I've just discovered that option() behaves differently than I anticipated. After reading the docs and searching with google I'm still confused how

Re: [CMake] Does CMake support the --question option for GNU Makefiles?

I think this is just a misunderstanding and not related to CMake. Make --question mode always returns a 1 if the target is PHONY because these targets are always out of date. The Makefiles generated by CMake use a top level PHONY target (and other PHONY targets as well)

Re: [cmake-developers] [CMake] dependencies of cross compiliations

Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer a écrit : > Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not asked before. I work in the embedded > > field and there it is usually to have at least two different build > > platforms. The Host platform, where

Re: [CMake] dependencies of cross compiliations

Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer a écrit : > Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not asked before. I work in the embedded > > field and there it is usually to have at least two different build > > platforms. The Host platform, where

[CMake] Does CMake support the --question option for GNU Makefiles?

We are using cmake for our project and recently discovered that the generated Makefiles do not seem to work correctly with the '--question' or '-q' option. The return code is always '1' even if there are no changes which would require rebuilding/recompiling anything. I am not sure if this is an

Re: [CMake] dependencies of cross compiliations

I like the idea, some tweaks that I think you need add_host_build - executables built here need to be available not as targets, but as variables as if FIND_EXECUTABLE was called on them. This is probably what you meant, but it didn't come across that way. In the case where you are cross

Re: [CMake] Can an option enforce a default, even if cache is present?

Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer a écrit : > > Dear all, > > I've just discovered that option() behaves differently than I anticipated. > After reading the docs and searching with google I'm still confused how to > achieve my desired behaviour. > > What I've just learned is that

Re: [CMake] Can an option enforce a default, even if cache is present?

On 27/11/2018 13:49, Mario Emmenlauer wrote: I've just discovered that option() behaves differently than I anticipated. After reading the docs and searching with google I'm still confused how to achieve my desired behaviour. What I've just learned is that unspecified options take their cached

Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Le mar. 27 nov. 2018 à 14:56, Mario Emmenlauer a écrit : > > Dear Eric, > > just to let you know, your suggestion of using a post-install-script > for all system-wide links and files was indeed the solution to a working > RPM package. Now my files are completely encapsulated in /opt/PKGNAME/ >

Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Dear Eric, just to let you know, your suggestion of using a post-install-script for all system-wide links and files was indeed the solution to a working RPM package. Now my files are completely encapsulated in /opt/PKGNAME/ and install works fine. Cheers and Thanks, Mario On 23.11.18

[Cmake-commits] CMake branch, master, updated. v3.13.0-546-gf49efe2

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

[Cmake-commits] CMake branch, release, updated. v3.13.0-6-g2cf836f

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

[CMake] Can an option enforce a default, even if cache is present?

Dear all, I've just discovered that option() behaves differently than I anticipated. After reading the docs and searching with google I'm still confused how to achieve my desired behaviour. What I've just learned is that unspecified options take their cached value and do *not* go back to their

Re: [CMake] building host tools during cross compiliations (was: dependencies of cross compiliations)

On 11/27/18 5:28 AM, Rolf Eike Beer wrote: > Then I came up with: > >add_host_build("relative source dir" "build dir" [VARS]) > > This would create an entirely new CMake scope (with it's own > CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", > and would not take the

Re: [cmake-developers] [CMake] building host tools during cross compiliations (was: dependencies of cross compiliations)

On 11/27/18 5:28 AM, Rolf Eike Beer wrote: > Then I came up with: > >add_host_build("relative source dir" "build dir" [VARS]) > > This would create an entirely new CMake scope (with it's own > CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", > and would not take the

Re: [CMake] dependencies of cross compiliations

> which I bet all of us would love to see. This is not correct. I would strongly prefer they continue with QBS instead. Cmake is defacto, but very suboptional. On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not

Re: [cmake-developers] [CMake] dependencies of cross compiliations

> which I bet all of us would love to see. This is not correct. I would strongly prefer they continue with QBS instead. Cmake is defacto, but very suboptional. On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not

Re: [cmake-developers] [CMake] dependencies of cross compiliations

Am 2018-11-09 10:04, schrieb Torsten Robitzki: Hi, I hope this question was not asked before. I work in the embedded field and there it is usually to have at least two different build platforms. The Host platform, where unit tests are build (and where CMake is running) and an embedded Target

Re: [CMake] dependencies of cross compiliations

Am 2018-11-09 10:04, schrieb Torsten Robitzki: Hi, I hope this question was not asked before. I work in the embedded field and there it is usually to have at least two different build platforms. The Host platform, where unit tests are build (and where CMake is running) and an embedded Target

[CMake] Cmake Boost::boost target PRIVATE link, forcing dependency on client

I am having a problem with make 3.12 (windows) and cmake version 3.13.0-rc2 (linux). I am attempting to link boost headers privately to a static library, which is then linked by a client executable, that I do not want to depend on boost. According to the docs, the find_package(Boost) provides