Re: [CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
Are you thinking of tools that are invoked instead of the compiler, like clazy- standalone? I thought about mentioning a potential interest of my idea for using such tools (but forgot in the end). Yes, that and all the other tools supported by CMake as a "pre-command" before the compiler invocation (e.g. clang-tidy, iwyu,...) Specific support for -fsyntax-only may not be relevant for those tools, but a build mode where the final step of each build product is not taken would probably be useful there, indeed. Such a mode might even create an empty file with the intended name, so that there's something to refer to later during a build. I've been considering to write a little wrapper one could "inject" using CMAKE__COMPILER_LAUNCHER but there is no equivalent for the final product generation step (linker, librarian). So if we can achieve a light build mode, that would be great. In my case I could completely deactivate the build part including the syntax checking since that's done by the static analysis tools anyway. You'd get that by setting your analysis tool as the compiler. I did not think of doing that. I'll have to play with it, but I think the final product step will still be an issue. Sylvain -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
I'd also like something like that for another use case of mine which stumble upon the same limitations (compiler checks, linking and Qt generated content). My use case is for static analysis builds. For example, my CI setup has multiple of them including cppcheck, clang-tidy and iwyu through the CMake integration. And since I'd like to keep separate builds for each of them this requires 3 full build whose results I don't really care. So if we can achieve a light build mode, that would be great. In my case I could completely deactivate the build part including the syntax checking since that's done by the static analysis tools anyway. Thinking of that maybe we can completely disable the build invocation and add support for a "syntax only" analysis tool that would feats your need. Anyhow, we can't deactivate all the build. As you said auto-generated content, custom targets,... would need to stay. Sylvain Le 09/10/2018 à 16:38, René J.V. Bertin a écrit : Hi, Apologies, longish post ahead. I've tried to present my idea and the thought train leading up to it as succinctly as possible. Hope I at least strike a chord! Clang and GCC have long supported an option that makes them stop after the syntax-verification stage: -fsyntax-only . This has the advantage (see below) that it's much faster than a regular build and that no output is generated. The absent output is also a problem and the reason I'm posting about it here: - compiler checking fails because of the missing output. - link and archive (static lib) creation fail because of missing files. The first problem should not be hard to fix (filter out -fsyntax-only from the arguments used to check the compiler). The 2nd problem can be addressed by ignoring the exit code from linking and archiving commands (possible with make, presumably with ninja too). Would it be feasible to implement "something" that makes it possible to run a full pure-syntax-checking "build", either as a special target or as a separate mode of operation or CMAKE_BUILD_TYPE? I think this could be useful in general esp. with larger projects, allowing to check "quickly" if a change (triggering a full rebuild) breaks something. QtWebKit would be an appropriate example: it uses a central header to set the configuration preprocessor tokens so toggling even one of these switches causes *everything* to be rebuilt. Some more observations which outline a context where cmake-level support for a pure syntax-checking run would be beneficial (also the context that made me remember the -fsyntax-only option): - a number of IDEs (can) use CMake as the basis for project definition. - They also provide parsing facilities that also use information from cmake to control the parser. - KDE has long used cmake instead of autoconf (or qmake) and is based on Qt, which means KDE projects depend on auto-generation of files which need to be included in C++ code. - Parsing or even syntax-checking won't work to at least some degree without those auto-generated files. - opening a project in an IDE is not always done with the intention to build it; in absence of such an intention one usually does expect to be able to rely on parsing and syntax checking. - Auto-generation of Qt's automatic content occurs during a full build, when needed. That last observation is the big bottleneck; a full build can be very costly. If there were a dedicated target to generate just all automatic content one could just build that target and there would be no issue left. Whether or not this is impossible is unclear, and at least not entirely a CMake issue. Here too something like -DCMAKE_BUILD_TYPE=SyntaxOnly would be a workable solution. R. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Debugger for CMake
Le 30/01/2017 à 17:09, Justin Berger a écrit : a) Is this feature worthwhile for eventual merge into CMake? No doubt! :-) > c) What is the best approach to make this kind of feature appealing to IDE / UI tools which currently work with CMake? If I recall correctly, one of the initial use cases for the server mode was exactly that. The very first prototype of Stephen Kelly had this feature and could trace were a variable was last modified, make a diff of the CMake state between two locations in a CMake script,... I didn't look at your code and I'll let the server mode maintainers give their feedback too but I guess the best way to go would be to jump in server mode to add that. Besides, the server mode is especially designed to be IDE friendly. Sylvain -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Disabling leaks check when using Address Sanitizer
Hi everyone, I've setup some sanitizer builds on my project and I'd like to have two separate builds for asan and lsan, meaning I want to disable leak detection in the asan build. I've managed to correctly setup the CTEST_MEMORYCHECK_SANITIZER_OPTIONS with "detect_leaks=0" and at runtime (ctest_memcheck) the ASAN_OPTIONS is populated with my custom value. The issue is that CMake appends its own "detect_leak=1" (while "log_file=..." is prepended). It overrides my own option which has then no effect. I see two possible fixes here: 1- Since "detect_leaks=1" is the default, we can simply not append it to the options and make sure the user options are last 2- If we still want to explicitly set "detect_leaks=1", I'd suggest to prepend it, like "log_file=", to the user options so that anyone can override them if need be The related code seems to be at: 25d7b883 : Source/CTest/cmCTestMemCheckHandler.cxx:600 If my analysis is correct I can make a MR. Which fixes would you prefer? Regards, Sylvain -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] Warnings with newer versions of Boost imported targets
Hi, I'm using CMake 3.6.3 (so up-to-date version at this point). After updating my Boost libraries to the newest version (1.62 just landed on my Debian testing) I get a bunch of warnings: "Imported targets not available for Boost version 106200" There seems to be a fallback behavior working fine, so I'm not blocked but these warnings are very annoying. I see that support for version 1.62 has been added in CMake with 9bb8ac8 and a997cac and will be available in CMake 3.7 My questions would be: 1- Does this mean that CMake can't use imported targets on Boost versions it doesn't know explicitly? (the fallback behavior does not seem to have this problem) 2- Does that mean I can't update my boost version without also updating my CMake version? (which for this specific use case cannot be done until the next CMake version) 3- Is there a way to fix/disable these warnings in a proper way? Thanks, Sylvain -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency
Hello,
Please find attached a patch that corrects a typo and a inconsistency in a
code snippet.
The patch is based on the 'release' branch.
Regards,
Sylvain
From c861c3341a59ca635f98e6f56caee7104f16dc32 Mon Sep 17 00:00:00 2001
From: Sylvain Joubert <joubert...@gmail.com>
Date: Fri, 21 Oct 2016 15:46:12 +0200
Subject: [PATCH] Help: Fix cmake-server typo and message type consistency
---
Help/manual/cmake-server.7.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Help/manual/cmake-server.7.rst b/Help/manual/cmake-server.7.rst
index afd4e2b..a3a4237 100644
--- a/Help/manual/cmake-server.7.rst
+++ b/Help/manual/cmake-server.7.rst
@@ -403,7 +403,7 @@ CMake will reply like this (after reporting progress for some time)::
Type "compute"
^^
-This requist will generate build system files in the build directory and
+This request will generate build system files in the build directory and
is only available after a project was successfully "configure"d.
Example::
@@ -520,7 +520,7 @@ sourceDirectory of the target.
Example::
[== CMake Server ==[
- {"type":"project"}
+ {"type":"codemodel"}
]== CMake Server ==]
CMake will reply::
@@ -529,7 +529,7 @@ CMake will reply::
{
"cookie":"",
"type":"reply",
-"inReplyTo":"project",
+"inReplyTo":"codemodel",
"projects":
[
--
2.9.3
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] bash-completion: Fix cmake -E lookup
Hi,
Please find attached a fix for the completion of the '-E' option.
The 'sed' match was not strong enough and took into account the wrapped
description text of long commands. This should now be fixed.
Regards,
Sylvain
>From e6312fb56b04ec653fd314df77881b38c1ff7dd0 Mon Sep 17 00:00:00 2001
From: Sylvain Joubert <joubert...@gmail.com>
Date: Thu, 4 Aug 2016 18:59:21 +0200
Subject: [PATCH] bash-completion: Fix cmake -E lookup
In case of long ' ' the description text is wrapped
and indented on the next line.
Avoid taking these lines into account by explicitly requiring the third
character to be a non-space.
---
Auxiliary/bash-completion/cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Auxiliary/bash-completion/cmake b/Auxiliary/bash-completion/cmake
index 6061129..0a862fa 100644
--- a/Auxiliary/bash-completion/cmake
+++ b/Auxiliary/bash-completion/cmake
@@ -102,7 +102,7 @@ _cmake()
;;
-E)
COMPREPLY=( $( compgen -W "$( cmake -E help |& sed -n \
-'/^ /{s|^ \([^ ]\{1,\}\) .*$|\1|;p}' 2>/dev/null )" \
+'/^ [^ ]/{s|^ \([^ ]\{1,\}\) .*$|\1|;p}' 2>/dev/null )" \
-- "$cur" ) )
return
;;
--
2.8.1
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] GCC: -std=g++14 vs -std=c++14
Le 13/06/2016 11:36, Patrick Boettcher a écrit : Hi list, I'm using gcc for a c++14-based project. To have cmake add the corresponding -std=-flag I'm setting set_property(TARGET PROPERTY CXX_STANDARD 14) This makes that when gcc is used cmake adds -std=gnu++14 . How can I make it set -std=c++14 instead? Hi, You also need to correctly set the CXX_EXTENSIONS properties to get a standard standard. You might also want to take a look at the CXX_STANDARD_REQUIRED property. Sylvain -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] CMP0058 warning on configure-time generated source files
Hi, In my project I have some source files that are generated at configure time. Much like configure_file but using one execute_process call with an external executable, then a second execute_process with cmake -E copy_if_different to avoid unnecessary rebuild. The generated files (from the build folder) are then used as source file for some targets. I recently upgraded to CMake >= 3.3 and I get a CMP0058 warning on some of the generated files. What I don't understand is that: - These files are not generated at build time but at configure time, why can't they just be seen as regular source files? - I generate lots of these files, but only some (only a few proportionally) are listed in the warning. I haven't been able to see a pattern yet and the build.ninja seems to contain equivalent rules both for the warned and the not warned files. What am I missing here? Thanks -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] [patch] FindBoost: Mark Boost_LIBRARY_DIR_[RELEASE, DEBUG] cache entries as advanced
Hello,
The recent development to support different LIBRARY_DIR for Boost have
made the new cache entries appear in the default cache.
I have searched in the code history of the FindBoost.cmake file to find
why the old Boost_LIBRARY_DIR was marked as advanced while the new
ones do not, ... and I failed.
Especially, I couldn't find any mark_as_advanced(Boost_LIBRARY_DIR) that
was not reported to the new variables
I am guessing either there is something weird, a bug elsewhere or I'm
most likely missing something.
If someone is able to find the explanation it would be nice.
Anyway, here is a patch that marks the new variables as advanced.
But, depending on the answer to my history related interrogation it may
not be the best patch to fix the issue.
Sylvain
From feeebe8666883eab6b638ce7771a015ea229d503 Mon Sep 17 00:00:00 2001
From: Sylvain Joubert joubert...@gmail.com
Date: Sat, 30 May 2015 15:32:03 +0200
Subject: [PATCH] FindBoost: Mark Boost_LIBRARY_DIR_[RELEASE,DEBUG] cache
entries as advanced
---
Modules/FindBoost.cmake | 1 +
1 file changed, 1 insertion(+)
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index c844aed..21883eb 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -330,6 +330,7 @@ macro(_Boost_FIND_LIBRARY var build_type)
if(NOT Boost_LIBRARY_DIR_${build_type})
get_filename_component(_dir ${${var}} PATH)
set(Boost_LIBRARY_DIR_${build_type} ${_dir} CACHE PATH Boost library directory ${build_type} FORCE)
+ mark_as_advanced(Boost_LIBRARY_DIR_${build_type})
endif()
elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
# Try component-specific hints but do not save Boost_LIBRARY_DIR_[RELEASE,DEBUG].
--
2.1.4
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [patch] Configure some targets with USES_TERMINAL
Hi all,
Please find attached a patch that adds the USES_TERMINAL configuration
to some targets.
These targets are good candidates to use the Ninja 'console' pool since
they are likely to be built on their own and may take some time to complete.
Sylvain
From 7d786455f5f7c8e63651b8f3d9cbb581970b9e39 Mon Sep 17 00:00:00 2001
From: Sylvain Joubert joubert...@gmail.com
Date: Sat, 24 Jan 2015 19:42:31 +0100
Subject: [PATCH] Configure some targets with USES_TERMINAL
This will make them use the 'console' pool with the Ninja generator.
Impacted targets are:
- Built-in targets: install, install/local, install/strip, tests,
package, package_source, rebuild_cache
- Targets provided by the CTestTargets module: Nightly, Continuous,
Experimental,
and all their variants (*Start, *Configure, ...)
---
Modules/CTestTargets.cmake | 3 +++
Source/cmGlobalGenerator.cxx | 14 +++---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/Modules/CTestTargets.cmake b/Modules/CTestTargets.cmake
index 5b6e062..1157850 100644
--- a/Modules/CTestTargets.cmake
+++ b/Modules/CTestTargets.cmake
@@ -67,6 +67,7 @@ if(NOT _CTEST_TARGETS_ADDED)
foreach(mode Experimental Nightly Continuous NightlyMemoryCheck)
add_custom_target(${mode}
${CMAKE_CTEST_COMMAND} ${__conf_types} -D ${mode}
+ USES_TERMINAL
)
set_property(TARGET ${mode} PROPERTY RULE_LAUNCH_CUSTOM )
set_property(TARGET ${mode} PROPERTY FOLDER CTestDashboardTargets)
@@ -82,6 +83,7 @@ if(NOT _CTEST_TARGETS_ADDED)
)
add_custom_target(${mode}${testtype}
${CMAKE_CTEST_COMMAND} ${__conf_types} -D ${mode}${testtype}
+ USES_TERMINAL
)
set_property(TARGET ${mode}${testtype} PROPERTY RULE_LAUNCH_CUSTOM )
set_property(TARGET ${mode}${testtype} PROPERTY FOLDER CTestDashboardTargets)
@@ -94,6 +96,7 @@ if(NOT _CTEST_TARGETS_ADDED)
if(CTEST_TEST_TARGET_ALIAS)
add_custom_target(${CTEST_TEST_TARGET_ALIAS}
${CMAKE_CTEST_COMMAND} ${__conf_types}
+ USES_TERMINAL
)
endif()
endif()
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index dd3b1ec..4c95a9f 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2191,7 +2191,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
= this-CreateGlobalTarget(this-GetPackageTargetName(),
Run CPack packaging tool...,
cpackCommandLines, depends,
- workingDir.c_str(), /*uses_terminal*/false);
+ workingDir.c_str(), /*uses_terminal*/true);
}
// CPack source
const char* packageSourceTargetName = this-GetPackageSourceTargetName();
@@ -2215,7 +2215,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
= this-CreateGlobalTarget(packageSourceTargetName,
Run CPack packaging tool for source...,
cpackCommandLines, depends,
- workingDir.c_str(), /*uses_terminal*/false);
+ workingDir.c_str(), /*uses_terminal*/true);
}
}
@@ -2241,7 +2241,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
(*targets)[this-GetTestTargetName()]
= this-CreateGlobalTarget(this-GetTestTargetName(),
Running tests..., cpackCommandLines, depends, 0,
-/*uses_terminal*/false);
+/*uses_terminal*/true);
}
//Edit Cache
@@ -2296,7 +2296,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
(*targets)[rebuildCacheTargetName] =
this-CreateGlobalTarget(
rebuildCacheTargetName, Running CMake to regenerate build system...,
-cpackCommandLines, depends, 0, /*uses_terminal*/false);
+cpackCommandLines, depends, 0, /*uses_terminal*/true);
}
//Install
@@ -2377,7 +2377,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
(*targets)[this-GetInstallTargetName()] =
this-CreateGlobalTarget(
this-GetInstallTargetName(), Install the project...,
-cpackCommandLines, depends, 0, /*uses_terminal*/false);
+cpackCommandLines, depends, 0, /*uses_terminal*/true);
// install_local
if(const char* install_local = this-GetInstallLocalTargetName())
@@ -2393,7 +2393,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
(*targets)[install_local] =
this-CreateGlobalTarget(
install_local, Installing only the local directory...,
- cpackCommandLines, depends, 0, /*uses_terminal*/false);
+ cpackCommandLines, depends, 0, /*uses_terminal*/true);
}
// install_strip
@@ -2410,7 +2410,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
(*targets)[install_strip
Re: [CMake] Rename target RUN_TESTS
Le 02/01/2015 05:27, Scott Aron Bloom a écrit : Is there a CMake command to rename a target? I don't think you can rename a target. We would like to name it ALL_RUN_TEST However, you can add a custom target that depends on the misnamed one: if(MSVC) add_custom_target(ALL_RUN_TEST ALL DEPENDS RUN_TESTS) endif() This way the target is not renamed but you have at your disposal a new target that will do and act the same, with a name better suited to your needs. Sylvain -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Rename target RUN_TESTS
Le 02/01/2015 11:43, Sylvain Joubert a écrit : if(MSVC) add_custom_target(ALL_RUN_TEST ALL DEPENDS RUN_TESTS) endif() The ALL dependency should not be there. No need to run the tests at every compilation. This is better: if(MSVC) add_custom_target(ALL_RUN_TEST DEPENDS RUN_TESTS) endif() Sylvain -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
Le 03/10/2014 17:41, Matthew Woehlke a écrit : On 2014-10-03 08:56, Brad King wrote: I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). I quickly checked if it is possible. Unlike the rerun target which is manually added by the Ninja generator, the install and package targets are handled in a generic way by the utility target generator. Thus, handling these targets is not as straightforward as rerun. I'll keep digging a bit, maybe I can find a way to do it. ;-) -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
Hi,
Since Ninja 1.5, a pre-defined pool 'console' can be used for non
buffered output.
See
http://martine.github.io/ninja/manual.html#_the_literal_console_literal_pool
This patch specifies that special pool for the build.ninja build block
if the Ninja version used is at least 1.5
This is useful for projects that have a long and verbose CMake run step.
The idea is to get the output as soon as possible.
It also adds the generation of the minimal required version of Ninja in
the build.ninja file. The default version is 1.3 since the generator
uses features from that version. If the Ninja version is 1.5 or greater,
then the generator will use the 'console' pool and the build.ninja file
requires at least Ninja 1.5
Regards,
Sylvain
From 5735b36d3c8780da06c9a91b461946a814d4592b Mon Sep 17 00:00:00 2001
From: Sylvain Joubert joubert...@gmail.com
Date: Thu, 2 Oct 2014 21:21:05 +0200
Subject: [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
The pre-defined 'console' pool is a non-buffered pool that runs
with a depth of 1
CMake re-run cannot be run concurrently and it will eventually
output something
A non-buffered pool allows to get it as soon as possible
Also, generate the minimal required version of Ninja in the build file
---
Source/cmGlobalNinjaGenerator.cxx | 23 ++-
Source/cmGlobalNinjaGenerator.h | 3 ++-
Source/cmLocalNinjaGenerator.cxx | 25 +
Source/cmLocalNinjaGenerator.h| 1 +
4 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 50e1abb..543ecdb 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -1128,6 +1128,16 @@ void cmGlobalNinjaGenerator::WriteTargetRebuildManifest(std::ostream os)
implicitDeps.erase(std::unique(implicitDeps.begin(), implicitDeps.end()),
implicitDeps.end());
+ cmNinjaVars variables;
+ // Use 'console' pool to get non buffered output of the CMake re-run call
+ // Available since Ninja 1.5
+ if(cmSystemTools::VersionCompare(cmSystemTools::OP_LESS,
+ ninjaVersion().c_str(),
+ 1.5) == false)
+{
+variables[pool] = console;
+}
+
this-WriteBuild(os,
Re-run CMake if any of its inputs changed.,
RERUN_CMAKE,
@@ -1135,7 +1145,7 @@ void cmGlobalNinjaGenerator::WriteTargetRebuildManifest(std::ostream os)
/*explicitDeps=*/ cmNinjaDeps(),
implicitDeps,
/*orderOnlyDeps=*/ cmNinjaDeps(),
- /*variables=*/ cmNinjaVars());
+ variables);
this-WritePhonyBuild(os,
A missing CMake input file is not an error.,
@@ -1154,6 +1164,17 @@ std::string cmGlobalNinjaGenerator::ninjaCmd() const
return ninja;
}
+std::string cmGlobalNinjaGenerator::ninjaVersion() const
+{
+ std::string version;
+ std::string command = ninjaCmd() + --version;
+ cmSystemTools::RunSingleCommand(command.c_str(),
+ version, 0, 0,
+ cmSystemTools::OUTPUT_NONE);
+
+ return version;
+}
+
void cmGlobalNinjaGenerator::WriteTargetClean(std::ostream os)
{
WriteRule(*this-RulesFileStream,
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index 4cbbeea..a192eee 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -297,6 +297,8 @@ public:
void AddTargetAlias(const std::string alias, cmTarget* target);
virtual void ComputeTargetObjectDirectory(cmGeneratorTarget* gt) const;
+
+ std::string ninjaVersion() const;
protected:
/// Overloaded methods. @see cmGlobalGenerator::Generate()
@@ -335,7 +337,6 @@ private:
std::string ninjaCmd() const;
-
/// The file containing the build statement. (the relation ship of the
/// compilation DAG).
cmGeneratedFileStream* BuildFileStream;
diff --git a/Source/cmLocalNinjaGenerator.cxx b/Source/cmLocalNinjaGenerator.cxx
index 2ac8363..5522e0d 100644
--- a/Source/cmLocalNinjaGenerator.cxx
+++ b/Source/cmLocalNinjaGenerator.cxx
@@ -189,6 +189,7 @@ void cmLocalNinjaGenerator::WriteBuildFileTop()
{
// For the build file.
this-WriteProjectHeader(this-GetBuildFileStream());
+ this-WriteNinjaRequiredVersion(this-GetBuildFileStream());
this-WriteNinjaFilesInclusion(this-GetBuildFileStream());
// For the rule file.
@@ -205,6 +206,30 @@ void cmLocalNinjaGenerator::WriteProjectHeader(std::ostream os)
cmGlobalNinjaGenerator::WriteDivider(os);
}
+void cmLocalNinjaGenerator::WriteNinjaRequiredVersion(std::ostream os)
+{
+ // Default required version
+ // Ninja generator uses 'deps' and 'msvc_deps_prefix' introduced in 1.3
+ std::string requiredVersion = 1.3;
+
+ // Ninja generator uses the 'console' pool if available (= 1.5)
+ std::string usedVersion
[cmake-developers] [PATCH] Prevent compilers to be silently modified when using Ninja, generator
Hi,
Please find attached a patch that fixes Ninja generator.
Unlike Unix Makefiles generator it was possible to change compiler path
without being notified, without the cache being deleted and more
important the generated Ninja solution was not updated with the new
compilers while the CMake cache was.
I also activated the tests for this feature when building/testing CMake
using Ninja
Regards,
Sylvain
From e68aa37ebcb249293ffde51ba7999ef988770cd0 Mon Sep 17 00:00:00 2001
From: Sylvain Joubert joubert...@gmail.com
Date: Sat, 20 Sep 2014 22:37:52 +0200
Subject: [PATCH] Prevent compilers to be silently modified when using Ninja
generator
Unlike with Unix Makefiles generator modifying compiler paths was not
protected with Ninja generator
It was possible to modify them in the cache without the expected effect
on the generated solution
Also activate corresponding tests with Ninja
---
Source/cmGlobalNinjaGenerator.cxx | 9 +
Tests/RunCMake/CMakeLists.txt | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 09ee128..50e1abb 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -540,6 +540,15 @@ void cmGlobalNinjaGenerator
cmSystemTools::Error(The Ninja generator does not support Fortran yet.);
}
this-cmGlobalGenerator::EnableLanguage(langs, makefile, optional);
+ for(std::vectorstd::string::const_iterator l = langs.begin();
+ l != langs.end(); ++l)
+{
+if(*l == NONE)
+ {
+ continue;
+ }
+this-ResolveLanguageCompiler(*l, makefile, optional);
+}
}
bool cmGlobalNinjaGenerator::UsingMinGW = false;
diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index 549aed8..fd3bb03 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -50,7 +50,7 @@ add_RunCMake_test(CMP0051)
add_RunCMake_test(CMP0053)
add_RunCMake_test(CMP0054)
add_RunCMake_test(CTest)
-if(UNIX AND ${CMAKE_GENERATOR} MATCHES Unix Makefiles)
+if(UNIX AND ${CMAKE_GENERATOR} MATCHES Unix Makefiles|Ninja)
add_RunCMake_test(CompilerChange)
endif()
add_RunCMake_test(CompilerNotFound)
--
2.1.0
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [patch] Bash completion for label options of ctest
Hi, Please find attached a patch that updates the bash completion of ctest. It will now be able to complete the -L,-LE options and their long versions. Regards, Sylvain From 8361c9dae1540c23b5529bfb6bb4de3670ecd88a Mon Sep 17 00:00:00 2001 From: Sylvain Joubert joubert...@gmail.com Date: Wed, 3 Sep 2014 20:26:17 +0200 Subject: [PATCH] Add bash completion for label options of ctest --- Auxiliary/bash-completion/ctest | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest index 25cb998..327e12c 100644 --- a/Auxiliary/bash-completion/ctest +++ b/Auxiliary/bash-completion/ctest @@ -19,8 +19,12 @@ _ctest() _filedir return ;; --L|--label-regex|-LE|--label-exclude|--track|-I|--tests-information|\ ---max-width|--timeout|--stop-time) +-L|--label-regex|-LE|--label-exclude) +COMPREPLY=( $( compgen -W '$( ctest --print-labels 2/dev/null | +grep ^ 2/dev/null | cut -d -f 3 )' -- $cur ) ) +return +;; +--track|-I|--tests-information|--max-width|--timeout|--stop-time) # argument required but no completions available return ;; -- 2.1.0 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] Support for swig 3.0
Le 06/07/2014 21:34, Julien Schueller a écrit : This is curious, SWIG does not provide an executable named swig3.0. Where did you get swig from ? I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0' package. This package provides the '/usr/bin/swig3.0' executable. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [patch] Support for swig 3.0
Hi all,
Please consider this patch that makes swig 3.0 supported by the FindSWIG
module.
Sylvain
From e520170ce0c806616125eb125f94cdd364fedede Mon Sep 17 00:00:00 2001
From: Sylvain Joubert joubert...@gmail.com
Date: Sat, 5 Jul 2014 14:55:36 +0200
Subject: [PATCH] Add support for swig 3.0 application
---
Modules/FindSWIG.cmake | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Modules/FindSWIG.cmake b/Modules/FindSWIG.cmake
index 8bd4048..818d1f2 100644
--- a/Modules/FindSWIG.cmake
+++ b/Modules/FindSWIG.cmake
@@ -25,6 +25,7 @@
#=
# Copyright 2004-2009 Kitware, Inc.
# Copyright 2011 Mathieu Malaterre mathieu.malate...@gmail.com
+# Copyright 2014 Sylvain Joubert joubert...@gmail.com
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
@@ -36,7 +37,7 @@
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
-find_program(SWIG_EXECUTABLE NAMES swig2.0 swig)
+find_program(SWIG_EXECUTABLE NAMES swig3.0 swig2.0 swig)
if(SWIG_EXECUTABLE)
execute_process(COMMAND ${SWIG_EXECUTABLE} -swiglib
--
2.0.0
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
