[Cmake-commits] CMake branch, master, updated. v3.9.1-566-gfe19fda

_VERSION_MINOR 9) -set(CMake_VERSION_PATCH 20170823) +set(CMake_VERSION_PATCH 20170824) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] CMake + Gradle for Android

On Thu, Aug 24, 2017 at 5:20 AM, Jom O'Fisher wrote: > We'll definitely be discussing this use case at our next C++ meeting and > I'll also be checking for myself whether ccache will work in this CMake > scenario. If ccache does work it seems like the natural level at which

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

Ok got it sorry to hear that certainly because, as soon as I hear something that would be useful somehow I end up needing it the next day. So sorry for us both. >From what your are saying (and I will take your word for it) the CMake has a another problem in not implementing "inherited build

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

> Does that work for your needs? Sadly, no (but thanks!). While this is enough for the arguably common use case of include directories, compile flags, etc... there are plenty of things that won't work with this approach. e.g. none of this works for instance: project(foo) add_library(blah

Re: [cmake-developers] PRE_BUILD misconception

It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen target more often than necessary (it could use PRE_BUILD instead). Let's assume a target `B` that depends on - a *GENERATED* file `FA` - a linked library `LA` - a utility target `TA` (via `add_dependencies()`) Using the VS

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

So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: @Jean-Michaël Celerier -- snip -- >* - Says that custom functions such as

Re: [CMake] CMake + Gradle for Android

By gradle module projects, I just mean the leaf build.gradle files as opposed to the root build.gradle. By configurations, I mean Build Types (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I will use the term "variant" rather than "configuration" to be precise. See this

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

On Wed, Aug 23, 2017 at 2:07 AM, Clément Gregoire wrote: > I can't argue too much why paths or absolute on cmake as I don't know the > rationale behind it is. While your point about command line limit makes > sense, I feel like a system limiting command line size to this extent

Re: [CMake] Regex Matching

On 23.08.2017 22:21, Andrew Bell wrote: Hi, Can someone please explain the cmake regex matching rules? The following returns true: if ("This is a test" MATCHES "test") I would have expected to have needed something like this to get a match: if ("This is a test" MATCHES ".*test") Does cmake

[CMake] Regex Matching

Hi, Can someone please explain the cmake regex matching rules? The following returns true: if ("This is a test" MATCHES "test") I would have expected to have needed something like this to get a match: if ("This is a test" MATCHES ".*test") Does cmake always search for a subexpression? Is

Re: [CMake] CMake + Gradle for Android

I'm not sure what you mean by "gradle module projects", but maybe having some examples of what you mean by "configurations, C++ flags, etc" might make it more clear. Question: When specifying "path" for the CMakeLists.txt in the build.gradle file, how do you know which targets to build? For

Re: [CMake] CMake, Mingw-w64 32 bit exception handling.

A quick scan of CMake source code shows that we don't have any references to gcc_eh anywhere. I way this could be occurring is through CMake detection of the implicit libraries that a compiler requires for each language. In particular it could be that C code for mingw by default uses gcc_eh while

Re: [CMake] CMake + Gradle for Android

Thanks for the write-up Robert. Having thought about it, I don't believe we have a satisfying answer at the gradle level for this kind of organization. In the gradle model module projects are the unit of organization for configurations, C/C++ flags, etc. and that's something we're pretty much

Re: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain

That would mean a lot of duplication for just redefining a particular value. Each compiler will have likely a way too handle the definition of multiple flags with the same purpose and based on that prepending or adding could be performed internally. Van: Brad

Re: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain

On 08/23/2017 11:27 AM, maikel van den Hurk wrote: > change ... optimisation from O3 (CMake internal setting) to O2. If you want to change the default flags instead of only adding (prepending) to them then you need to set all the flags by setting the cache entry directly. A toolchain file that

Re: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain

Thanks I was exactly looking for this in particularly, must have searched wrongly! Though I wonder for example how could I for example change in my toolchain file which is setting up a GCC based compiler for example in release context the optimisation from O3 (CMake internal setting) to O2.

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

2017-08-23 15:28 GMT+02:00 Clément Gregoire : > set_property(GROUP PluginGroup PROPERTIES /* whatever in >> cmake-properties*/) >> >> set_group(myTarget PluginGroup) // applies everything to the target > > > Isn't it the same as having a custom target/library for the

Re: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain

On 08/23/2017 09:56 AM, maikel van den Hurk wrote: > I was wondering why there is no ability to define > CMAKE__FLAGS(_) within a CMake Toolchain file, but still > benefit from the CMAKE__INIT_FLAGS(_) detected from CMake > internals. This has been possible since commit v3.7.0-rc1~392^2

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

On 08/23/2017 05:07 AM, masaru tsuchiyama wrote: > It seems your coworker can reproduce it and you can use the PC tomorrow. > So I don't need to debug it, right? Correct, thanks. See issue for further updates. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the

[cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain

I was wondering why there is no ability to define CMAKE__FLAGS(_) within a CMake Toolchain file, but still benefit from the CMAKE__INIT_FLAGS(_) detected from CMake internals. Is certain extension considered before? Or are then any reasons to not do this? Would be interested to hear if this

[Cmake-commits] CMake branch, master, updated. v3.9.1-565-gfa664d9

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

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

2017-08-23 14:10 GMT+02:00 Jean-Michaël Celerier < jeanmichael.celer...@gmail.com>: > > - Says that custom functions such as add_{project}_library shouldn't be > used and function definitions should be used as little as possible. Except > this just leads to extremely verbose CMakeLists where

[Cmake-commits] CMake branch, master, updated. v3.9.1-562-gfc1aaf1

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

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

> - Says that custom functions such as add_{project}_library shouldn't be used and function definitions should be used as little as possible. Except this just leads to extremely verbose CMakeLists where repeated properties are defined again and again and again. I also never understood how to

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

On 23.08.2017 11:44, Nicholas Devenish wrote: > - But simultaneously advocates rewriting internal functions using the > (undocumented?) '_' feature to access "previous definitions". Uses this > as one of the few examples of one of the steps as a method to allow a > script to change behaviour if

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

On 08/23/2017 05:15 AM, Craig Scott wrote: > how long until we up the minimum Visual Studio version from 2010 > to at least 2013? That's only blocked on me finding time to update the nightly testing infrastructure. It requires moving several builds to other machines. -Brad -- Powered by

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

On Wed, Aug 23, 2017 at 8:07 AM, Clément Gregoire wrote: > I entirely agree with for the rest. CMake badly documenting good practices > or even giving tutorials is an issue. Probably the biggest issue I found. I > myself still fight after years of using and experimenting with

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

Probably just asking what a number of people are now thinking, but if we're now requiring C++11 to build CMake, how long until we up the minimum Visual Studio version from 2010 to at least 2013? Seems a bit optimistic to still be trying to support 2010 as the minimum standard and also state C++11

[Cmake-commits] CMake branch, master, updated. v3.9.1-554-gac6660b

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

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

Hello It seems your coworker can reproduce it and you can use the PC tomorrow. So I don't need to debug it, right? Ifyou want me to do anything, le me know. Regards Masaru 2017年8月23日(水) 7:34 masaru tsuchiyama : > Hello > > I'm busy today. > So I'll try tomorrow or the day

[CMake] CMake, Mingw-w64 32 bit exception handling.

Greetings. I'm a developer on a fairly large project where I'm using CMake version 3.9.1 I primarily work on linux, but also cross compiles for windows using Mingw-w64 on my linux box. I have encountered an issue which I'm having some trouble figuring out. Running through some of my tests where

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

> > > > it looks like C++11 is now a requirement for CMake itself. > > > > > > Yes. We just merged this: > > > https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 > > > > > > but you beat us to the announcement. > > > > I saw the MR last week and was delighted. The iterator type

[Cmake-commits] CMake branch, master, updated. v3.9.1-552-g7526b1e

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

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

I can't argue too much why paths or absolute on cmake as I don't know the rationale behind it is. While your point about command line limit makes sense, I feel like a system limiting command line size to this extent is dumb if it doesn't allow reading more arguments through a file. (again, I don't