[cmake-developers] [CMake 0015666]: Ninja may unnecessarily relink on windows
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15666
==
Reported By:Nils Gladitz
Assigned To:
==
Project:CMake
Issue ID: 15666
Category: (No Category)
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-07-28 05:56 EDT
Last Modified: 2015-07-28 05:56 EDT
==
Summary:Ninja may unnecessarily relink on windows
Description:
I have the following windows specific test case:
cmake_minimum_required(VERSION 3.3)
project(Foo CXX)
if(NOT EXISTS test.cpp)
file(WRITE test.cpp __declspec(dllexport) void foo() {})
endif()
add_custom_target(touch
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_SOURCE_DIR}/test.cpp
)
add_library(foo SHARED test.cpp)
Steps to Reproduce:
I configured the given test project with the Ninja generator from a Visual
Studio 2013 (x64) environment.
1. ninja # builds the project as expected
2. ninja # outputs ninja: no work to do. as expected
3. ninja touch # touches test.cpp
4. ninja # recompiles and relinks as expected
5-n. ninja # unexpectedly relinks; expected is ninja: no work to do.
Additional Information:
It looks like the relink happens because the linker updates foo.dll but does not
touch foo.lib.
Which leads to (ninja -d explain):
ninja explain: output foo.lib older than most recent input
CMakeFiles/foo.dir/test.cpp.obj (459779794 vs 459780205)
ninja explain: foo.dll is dirty
[1/1] Linking CXX shared library foo.dll
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-28 05:56 Nils Gladitz New Issue
==
--
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] Java support
Hi, Here are some patches to enhance Java support. 0001 (FindJava.cmake): Defines now two new variables for idlj and jar signer tools: Java_IDLJ_EXECUTABLE and Java_JARSIGNER_EXECUTABLE 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for java sources specification. 0003 (UseJava.cmake): Extends install_jar and install_jni_symlink commands to support options DESTINATION and COMPONENT as alternative to actual syntax. 0004 (UseJava.cmake): Add new command create_javah to wrap java tool javah. I also extends tests to support these extensions. This is my first contribution, so be indulgent if something is wrong… ;) Marc Chevrier 0001-Add-support-for-idlj-and-jarsigner-tools.patch Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch 0002-add_jar-now-supports-file-syntax-for-sources.patch Description: 0002-add_jar-now-supports-file-syntax-for-sources.patch 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch Description: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch 0004-Add-support-for-javah-tool.patch Description: 0004-Add-support-for-javah-tool.patch -- 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] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015
Hi dear CMake developers! 27.07.2015, 18:52, Brad King brad.k...@kitware.com: On 07/24/2015 03:46 AM, Konstantin Podsvirov wrote: To solve the problem you run cmake-gui is now possible with the following changes: Applied as two separate commits with minor tweaks: cmake-gui: Install Qt5 Windows platform plugin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42f0155b CMake: Add CMake_INSTALL_DEPENDENCIES option http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962 Code now in 'master' branch. Thanks, Brad! Meet/install/update modern CMake built on MSVC2015 c QtDialog based on Qt 5.5 from today :-) Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe cmake-gui should work now, but if not, then update your system and install Visual C++ Redistributable for Visual Studio 2015 from the link below: http://www.microsoft.com/en-us/download/details.aspx?id=48145 As always, questions and suggestions are welcome. -- Regards, Konstantin Podsvirov -- 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] check_cxx_source_compiles and include directories
On 07/27/2015 03:26 PM, Roman Wüger wrote: SubProj1 and SubProj2 does not find mutex, but check_cxx_source_compiles succeeds. Did I miss configure something here? The posted example works for me on Linux with g++ 4.9.3. The check succeeds and an executable I create in SubProj1 can #include mutex. I have /usr/include/c++/4.9.3/mutex right next to all the other C++ headers. -Brad -- 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] Strange behaviour with install(EXPORT)
On 07/27/2015 05:04 PM, Ben Boeckel wrote: Wouldn't an exported static library still need to inform others about its private non-exported static library dependencies though? For a shared library, ignoring static libraries in the private set would make sense. All the logic discussed in this thread is already conditioned on SHARED_LIBRARY targets. -Brad -- 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] check_cxx_source_compiles and include directories
Hi Brad, thanks for your investigation. I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from XCode 6 using Unix Makefiles as the generator. Best Regards Roman Am 28.07.2015 um 16:55 schrieb Brad King brad.k...@kitware.com: On 07/27/2015 03:26 PM, Roman Wüger wrote: SubProj1 and SubProj2 does not find mutex, but check_cxx_source_compiles succeeds. Did I miss configure something here? The posted example works for me on Linux with g++ 4.9.3. The check succeeds and an executable I create in SubProj1 can #include mutex. I have /usr/include/c++/4.9.3/mutex right next to all the other C++ headers. -Brad -- 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] check_cxx_source_compiles and include directories
On 07/28/2015 12:23 PM, Roman Wüger wrote: I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from XCode 6 using Unix Makefiles as the generator. Is that using the Xcode Command Line Tools or the /usr/bin/c++ stub that uses the /Applications/Xcode.app/.../bin/clang++ compiler underneath? Is CMAKE_OSX_SYSROOT set? Does -isysroot appear on the compilation command line? Thanks, -Brad -- 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] check_cxx_source_compiles and include directories
Thanks Brad yes, and that's the point. I've found my mistake, I had set the CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT between the check_cxx_source_compiles() calls and the add_subdirectory() calls. I moved the CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT initialization on top of the check_cxx_source_compiles() calls and everthing is working as expected. So, in my situation the order is: 1.) CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT 2.) check_cxx_source_compiles() and other platform checks 3.) add_subdirectory() and other stuff Best Regards Roman -Ursprüngliche Nachricht- Von: Brad King [mailto:brad.k...@kitware.com] Gesendet: Dienstag, 28. Juli 2015 18:50 An: Roman Wüger roman.wue...@gmx.at Cc: CMake MailingList cm...@cmake.org; CMake Developer MailingList cmake-developers@cmake.org Betreff: Re: [cmake-developers] check_cxx_source_compiles and include directories On 07/28/2015 12:23 PM, Roman Wüger wrote: I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from XCode 6 using Unix Makefiles as the generator. Is that using the Xcode Command Line Tools or the /usr/bin/c++ stub that uses the /Applications/Xcode.app/.../bin/clang++ compiler underneath? Is CMAKE_OSX_SYSROOT set? Does -isysroot appear on the compilation command line? Thanks, -Brad -- 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] Modules/GetPrequisites.cmake issues
Hi All,
attached is a patch that addresses some issues recently discussed on the
users list.
I'm no CMake expert so I don't know if I have done things in the best
way. One area I do not fully understand is how to detect MinGW, If I
could then objdump could be chosen as the preferred library dependency
walker over MS dumpbin.exe. See the patch description for details.
Regards
Bill Somerville.
From 203848c099026c23b5f70d395d0469887f099d23 Mon Sep 17 00:00:00 2001
From: Bill Somerville b...@classdesign.com
Date: Tue, 28 Jul 2015 22:40:36 +0100
Subject: [PATCH] For MinGW pre-filter objdump output for performance
As dumpbin.exe is no longer reliable for gcc libraries on MinGW
because it crashes on many common libraries like libgcc_s and
libgfortran it is now necessary too resort to using objdump for DLL
dependency walking. Using objdump has a secondary problem in that it
generates a lot of output for large libraries and causes
fixup_bundle() to take many minutes to process what took fractions of
a second with dumpbin.exe /dependents.
This patch includes a grep pre-filter in the execute_process() command
pipeline to reduce this output to a minimum for a several orders of
magnitude speed up. If grep isn't available the full output is used.
As there doesn't seem to be a reliable way of detecting MinGW callers
of fixup_bundle() may have to set the variable gp_tool to objdump if
dumpbin.exe is installed on the build machine to stop it using
dumpbin.exe for library dependency walking.
This patch also adds command status checking to the various
execute_process() invocations in GetPrerequisites.cmake so that they
don't fail silently producing invalid install packages.
---
Modules/GetPrerequisites.cmake | 53 ++
1 file changed, 49 insertions(+), 4 deletions(-)
diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake
index 23d486e..bbc1232 100644
--- a/Modules/GetPrerequisites.cmake
+++ b/Modules/GetPrerequisites.cmake
@@ -229,9 +229,14 @@ function(is_file_executable file result_var)
if(file_cmd)
execute_process(COMMAND ${file_cmd} ${file_full}
+RESULT_VARIABLE file_rv
OUTPUT_VARIABLE file_ov
+ERROR_VARIABLE file_ev
OUTPUT_STRIP_TRAILING_WHITESPACE
)
+ if(NOT file_rv STREQUAL 0)
+message(FATAL_ERROR ${file_cmd} failed: ${file_rv}\n${file_ev})
+ endif()
# Replace the name of the file in the output with a placeholder token
# (the string _file_full_ ) so that just in case the path name of
@@ -543,11 +548,21 @@ function(gp_resolved_file_type original_file file exepath
dirs type_var)
if(CYGPATH_EXECUTABLE)
execute_process(COMMAND ${CYGPATH_EXECUTABLE} -W
+ RESULT_VARIABLE env_rv
OUTPUT_VARIABLE env_windir
+ ERROR_VARIABLE env_ev
OUTPUT_STRIP_TRAILING_WHITESPACE)
+ if(NOT env_rv STREQUAL 0)
+message(FATAL_ERROR ${CYGPATH_EXECUTABLE} -W failed:
${env_rv}\n${env_ev})
+ endif()
execute_process(COMMAND ${CYGPATH_EXECUTABLE} -S
+ RESULT_VARIABLE env_rv
OUTPUT_VARIABLE env_sysdir
+ ERROR_VARIABLE env_ev
OUTPUT_STRIP_TRAILING_WHITESPACE)
+ if(NOT env_rv STREQUAL 0)
+message(FATAL_ERROR ${CYGPATH_EXECUTABLE} -S failed:
${env_rv}\n${env_ev})
+ endif()
string(TOLOWER ${env_windir} windir)
string(TOLOWER ${env_sysdir} sysroot)
@@ -709,6 +724,11 @@ function(get_prerequisites target prerequisites_var
exclude_system recurse exepa
set(gp_regex_error )
set(gp_regex_fallback )
set(gp_regex_cmp_count 1)
+# objdump generaates copious output so we create a grep filter to
pre-filter results
+find_program(gp_grep_cmd grep)
+if(gp_grep_cmd)
+ set(gp_cmd_filter ^[[:blank:]]*DLL Name: )
+endif()
else()
message(STATUS warning: gp_tool='${gp_tool}' is an unknown tool...)
message(STATUS CMake function get_prerequisites needs more code to handle
'${gp_tool}')
@@ -763,10 +783,30 @@ function(get_prerequisites target prerequisites_var
exclude_system recurse exepa
# Run gp_cmd on the target:
#
- execute_process(
-COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
-OUTPUT_VARIABLE gp_cmd_ov
-)
+ if(gp_cmd_filter) # filter is for performance
+execute_process(
+ COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
+ COMMAND ${gp_grep_cmd} ${gp_cmd_filter}
+ RESULT_VARIABLE gp_rv
+ OUTPUT_VARIABLE gp_cmd_ov
+ ERROR_VARIABLE gp_ev
+ )
+ else()
+execute_process(
+ COMMAND ${gp_cmd} ${gp_cmd_args} ${target}
+ RESULT_VARIABLE gp_rv
+ OUTPUT_VARIABLE gp_cmd_ov
+ ERROR_VARIABLE gp_ev
+ )
+
