MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015666CMake(No Category)public2015-07-28 05:562016-03-07 09:12
ReporterNils Gladitz 
Assigned ToNils Gladitz 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformWindowsOSOS Version
Product VersionCMake 3.3 
Target VersionCMake 3.4Fixed in VersionCMake 3.4 
Summary0015666: Ninja may unnecessarily relink on windows
DescriptionI 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 ReproduceI 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 InformationIt 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
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-07-28 05:56Nils GladitzNew Issue
2015-07-28 08:42Brad KingNote Added: 0039174
2015-07-28 08:54Nils GladitzNote Added: 0039175
2015-07-28 09:10Brad KingNote Added: 0039176
2015-07-28 09:14Nils GladitzNote Added: 0039177
2015-07-30 06:40Nils GladitzNote Added: 0039191
2015-07-30 06:40Nils GladitzStatusnew => closed
2015-07-30 06:40Nils GladitzAssigned To => Nils Gladitz
2015-07-30 06:40Nils GladitzResolutionopen => fixed
2015-07-30 06:40Nils GladitzFixed in Version => CMake 3.4
2015-07-30 08:48Brad KingNote Added: 0039192
2015-07-30 08:48Brad KingStatusclosed => resolved
2015-07-30 08:48Brad KingTarget Version => CMake 3.4
2015-07-30 08:58Nils GladitzNote Added: 0039194
2016-03-07 09:12Robert MaynardNote Added: 0040605
2016-03-07 09:12Robert MaynardStatusresolved => closed

Notes
(0039174)
Brad King   
2015-07-28 08:42   
We may need to add "restat = 1" to the build statement for the link rule.
(0039175)
Nils Gladitz   
2015-07-28 08:54   
The issue seems to exist since ef42e57d470db499a41c8bca695391c3e3e5cb86.

Adding the import library to byproducts (which then causes restat=1 to be added) instead of outputs seems to work around the issue for me.

I pushed ninja-implib-byproduct:
http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=35fb0bb8c09cfc5fd75ad87fac58799e5054b7ce [^]

Does that look ok?
(0039176)
Brad King   
2015-07-28 09:10   
Re 0015666:0039175: Yes, that looks just right. That's how I would have done it if I had known that the .lib might not be updated. Thanks!
(0039177)
Nils Gladitz   
2015-07-28 09:14   
Thanks, I mergeded it to next for testing.
(0039191)
Nils Gladitz   
2015-07-30 06:40   
"ninja-implib-byproduct" has been merged to master.
(0039192)
Brad King   
2015-07-30 08:48   
Thanks for updating. We typically keep issues initially at "resolved" to allow others to comment. After 4 months of inactivity then we close.
(0039194)
Nils Gladitz   
2015-07-30 08:58   
Ah alright ... I think I asked Robert on IRC at some point while he was still active and thought the poliy was:
- developer resolves issue
- issue reporter closes issue after verifying the issue is indeed resolved

I went straigt to close given that I was both.

I did see resolved, inactive issues being closed after a while ... but I thought that was just because the original reporter did not do so himself.
(0040605)
Robert Maynard   
2016-03-07 09:12   
Closing resolved issues that have not been updated in more than 4 months.