Re: [CMake] What is the default build type?

I like having something like this defines CMAKE_BUILD_TYPE to be a droplist of choices... if( NOT CMAKE_CONFIGURATION_TYPES ) set( CMAKE_CONFIGURATION_TYPES debug release ) endif( NOT CMAKE_CONFIGURATION_TYPES ) set( CMAKE_BUILD_TYPE release CACHE STRING "Cached cmake build type" )

[CMake] Source is not rebuild when header changes

Hello, on my project, which I'm currently testing with cmake, I just noticed, that when I modify a header, the project is not rebuilt. The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N The other CMakeLists.txt resides in root/src and lists all the source (*.cpp) files

Re: [CMake] Source is not rebuild when header changes

What source files include the header? Is one of them listed as a file in your project? Does the **including** file exist at CMake configure time, or is it generated later by a build step? What do the lines of code that include the header look like? CMake uses its own analysis of the source files

Re: [CMake] What is the default build type?

Hi, Am 01.08.2017 um 16:59 schrieb J Decker: > I like having something like this defines CMAKE_BUILD_TYPE to be a > droplist of choices... > > > > if( NOT CMAKE_CONFIGURATION_TYPES ) > set( CMAKE_CONFIGURATION_TYPES debug release ) > endif( NOT CMAKE_CONFIGURATION_TYPES ) > > set(

Re: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR

Am 1. August 2017 22:52:09 MESZ schrieb Brad King : >On 07/22/2017 07:33 AM, lec...@gmail.com wrote: >> So I downloaded the 3.9 release and thought my LTO nightmares we over >but >> cmake still isn't using CMAKE__COMPILER_AR when linking on >MSYS. > >The problem is that

Re: [CMake] Source is not rebuild when header changes

Am 01.08.2017 um 21:18 schrieb David Cole: > And in your file "src/CMakeLists.txt" do you add > "${CMAKE_CURRENT_SOURCE_DIR}" (or anything else which resolves to the > "src" directory) to your include directories? No, there is none. I do not added one, since it built correctly. I have no added

Re: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR

On 07/22/2017 07:33 AM, lec...@gmail.com wrote: > So I downloaded the 3.9 release and thought my LTO nightmares we over but > cmake still isn't using CMAKE__COMPILER_AR when linking on MSYS. The problem is that this code:

[CMake] [ANNOUNCE] CMake 3.9.0 Python wheels available for download

I am proud to announce that CMake 3.9.0 python wheels are now available for download using: pip install -U cmake See https://blog.kitware.com/cmake-python-wheels/ and https://pypi.python.org/pypi/cmake Documentation is available at: https://cmake.org/cmake/help/v3.9 Release notes are

Re: [CMake] Source is not rebuild when header changes

And in your file "src/CMakeLists.txt" do you add "${CMAKE_CURRENT_SOURCE_DIR}" (or anything else which resolves to the "src" directory) to your include directories? The line which includes the header is #include "mapping/..." but there is no local subdirectory "mapping" relative to that file

Re: [CMake] Source is not rebuild when header changes

Hi, Am 01.08.2017 um 18:32 schrieb David Cole via CMake: > What source files include the header? It's included by src/mapping/config/MappingConfiguration.cpp https://github.com/precice/precice/blob/develop/src/mapping/config/MappingConfiguration.cpp

[Cmake-commits] CMake branch, master, updated. v3.9.0-363-g611f162

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

Re: [cmake-developers] UseSWIG and enable_language(Java)

On 2017-08-01 16:29-0400 Brad King wrote: On 07/26/2017 06:02 AM, Alan W. Irwin wrote: [...] 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit UseSWIG: Record generated java files as custom command outputs Hmm. That causes swig_add_library's call to add_library to

Re: [cmake-developers] Module macros/function names with single leading underscore

On 07/23/2017 10:20 AM, Craig Scott wrote: > maybe it's worth considering renaming these single underscore > internal macros and functions? Projects that rely on the undocumented feature depend on being able to call the original function by prepending the single underscore. We can't change the

Re: [cmake-developers] UseSWIG and enable_language(Java)

On 07/26/2017 06:02 AM, Alan W. Irwin wrote: > enable_language(Java) FWIW this language support is quite limited, is not well tested, and has long been superseded by `UseJava.cmake`. I suggest porting away from it in PLplot. That will fix this too. > 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is