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

I think it is same as the issue. I use Japanese version of Win10 Pro. Regards. Masaru. 2017年8月22日(火) 0:11 Brad King : > On 08/21/2017 09:39 AM, Masaru Tsuchiyama wrote: > > I did git bisect. > > > > The problematic commit is > > >

Re: [CMake] CMake + Gradle for Android

This definitely a bit better, but still requires the boilerplate in each leaf gradle file. But I can't seriously complain too much. I think I'm more concerned with the implications this has underneath. First, let me ask just to make sure I'm not misunderstanding: Does each `externalNativeBuild`

Re: [CMake] CMake + Gradle for Android

You can find that number like this: - x = number of externalNativeBuild.cmake.path in your build.gradle files - y = number of gradle configurations (like debug and release) - z = number of ABIs that you build The result is x * y * z. To be more accurate, you should consider y and z to be

Re: [CMake] CMake + Gradle for Android

+ a colleague On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher wrote: > You can find that number like this: > - x = number of externalNativeBuild.cmake.path in your build.gradle files > - y = number of gradle configurations (like debug and release) > - z = number of ABIs that

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

Why does: Interface Libraries https://cmake.org/cmake/help/latest/command/add_library.html?highlight=add_library#id3 allow include directories via target_include_directories(INTERFACE) but not link_directories

[CMake] two llvm libraries.

Hello, I am developing two llvm libraries (they should as MODULE .so at he end). Still , they are situated in one cmake project and at some point I want to use one pass (library) inside another. Simply including h files and getting the result of llvm analysis leads to errors: Error opening

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

On 08/21/2017 09:39 AM, Masaru Tsuchiyama wrote: > I did git bisect. > > The problematic commit is > https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5361d48057c6f938e698a58 > > cmake with Ninja Generator succeeds by reverting > 690acadc17263621f5361d48057c6f938e698a58 [snip] >

Re: [CMake] CMake + Gradle for Android

Thanks this is very helpful. The other question I have is: Is there a place to centrally specify the root CMakeLists.txt? Basically, I want to specify the CMake root in 1 place, and have targets (defined further down in subdirectories) that require APK packaging to specify only the native target

Re: [CMake] CMake + Gradle for Android

How exactly does Gradle package *.so files in an APK? I know that ANT used to do this for any libs under "libs/". Does Gradle do some introspection into CMake targets to see if outputs are *.so, and copy those to some location if needed? What about libraries like libgnustl_shared.so that come with

Re: [CMake] CMake + Gradle for Android

Gradle does introspection on the CMake build to find .so targets and those get packaged. There is also a special case for stl/runtime .so files from the NDK. Any additional .so files need to specified in build.gradle using jniDirs On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey

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

Hello I did git bisect. The problematic commit is https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5361d48057c6f938e698a58 cmake with Ninja Generator succeeds by reverting 690acadc17263621f5361d48057c6f938e698a58 > git checkout master > git checkout -b

Re: [CMake] CMake + Gradle for Android

What you're doing already sounds correct. You can't directly specify CMakeLists.txt from the top-level build.gradle. Recommendation is that it should be specified from the build.gradle of the module of the APK. Is the issue that you have multiple APK modules that all reference the same CMake

Re: [CMake] CMake + Gradle for Android

Basically, yes. We have this sort of structure: / Applications/ App1/ build.gradle CMakeLists.txt App2/ build.gradle CMakeLists.txt App3/ build.gradle CMakeLists.txt CommonLib/

Re: [CMake] CMake + Gradle for Android

Would it work for your situation for the leaf CMakeLists.txt to include the root CMakeLists.txt? Then have the leaf-specific logic in the leaf CMakeLists.txt? On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey wrote: > Basically, yes. We have this sort of structure: > >

Re: [CMake] CMake + Gradle for Android

I wouldn't want to do that, it's too convoluted. I have other platforms that use these CMake scripts as well. For example, I run on Windows and Linux platforms as well to build the native code. Normal CMake behavior is designed to work at a root then go downwards to find targets. However it seems

Re: [CMake] CMake + Gradle for Android

Would it work for your scenario to provide properties in the root build.gradle: ext { cmakePath = file "CMakeLists.txt" } And then consume them in the leaf app/build.gradle like this? externalNativeBuild { cmake { path cmakePath } } It doesn't fully hide the details but it

Re: [cmake-developers] Update on toolset Clang with Microsoft CodeGen (v140_clang_c2) debug is broken

Clang/C2 is abandoned by MS. Look for some reddit posts by STL there. Clang/LLVM (5.0+) must be used with the VS2017(.3?) and higher. On older versions you can easily get endless list of errors. CMake needs to be tuned in terms of command line flags. I saw the same issue today. See ticket

[cmake-developers] Update on toolset Clang with Microsoft CodeGen (v140_clang_c2) debug is broken

Hi, I posted on 2016/05/02 about the fact that when generating Visual projects for clang_c2 debug was broken. The answer was: "Basically we need to have a different flag table for each possible toolset. Also it looks like additional special handling may be needed for PDBs and perhaps other

[Cmake-commits] CMake branch, master, updated. v3.9.1-537-g2d41ec5

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

Re: [cmake-developers] Best practice for providing inputs to find modules

On 08/17/2017 12:20 PM, Anh Huynh wrote: > If I want the user to provide inputs to select GPU targets [snip]> Should I have the user set a definition before using find_package> and checking for that definition? Yes. Document it as an input variable that can be set prior to the call. Either the

[Cmake-commits] CMake branch, master, updated. v3.9.1-516-g774d649

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

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

> Thread support would be nice because Autogen could be parallelized perfectly. oh please yes. moc generation is almost 10% of my build time. --- Jean-Michaël Celerier http://www.jcelerier.name On Mon, Aug 21, 2017 at 4:32 PM, Sebastian Holtermann wrote: > Am Montag,

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

Am Montag, 21. August 2017, 10:12:26 CEST schrieb Ben Boeckel: > On Mon, Aug 21, 2017 at 15:53:11 +0200, Sebastian Holtermann wrote: > > - std::array > > I don't see why not. > > > - std::basic_regex (and friends) > > Note that we require backwards compat with the old regex engine, so this >

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

On Mon, Aug 21, 2017 at 15:53:11 +0200, Sebastian Holtermann wrote: > - std::array I don't see why not. > - std::basic_regex (and friends) Note that we require backwards compat with the old regex engine, so this one needs to be used carefully and only on internal uses. > - std::thread (and

[Cmake-commits] CMake branch, master, updated. v3.9.1-534-gb14fdea

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

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

Hi, it looks like C++11 is now a requirement for CMake itself. That's good news. But does this mean *all* the nice features from the std library can be used? I'm especially interested in - std::array - std::basic_regex (and friends) - std::thread (and friends) - std::atomic_flag

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

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: https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 but you beat us to the announcement. > But does this mean *all* the nice features from the

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

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: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 > > but you beat us to