View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015754CMakeCMakepublic2015-09-21 10:542016-02-01 09:10
ReporterJohannes Asal 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformx64OSWindowsOS Version7
Product VersionCMake 3.3 
Target VersionCMake 3.4Fixed in VersionCMake 3.4 
Summary0015754: Visual Studio incremental build not working properly when target names start with a capital letter
DescriptionWhen using a target name starting with a capital letter (e.g. Mylibrary) in add_library (and probably also add_executable), GCC toolchains build fine but Visual Studio (tested with 2010 specifically) refuses to compile new .cpp files in the first incremental build after adding them to the CMakeLists.txt. However, it correctly detects that the CMakeLists.txt has changed and reconfigures accordingly. The second incremental build compiles the added files, which makes it even more strange. Please note that the bug occurs only when building via the CMake command line interface (cmake.exe --build). Building from within Visual Studio works always which is why I think it must be a problem with CMake.
Steps To ReproduceInstall Visual Studio 2010. Unzip the attached ZIP file. Open a command line in the /build subfolder and call

cmake -G"Visual Studio 10" ..

Then do a

cmake --build .

Watch how test1.cpp is compiled properly. Then open CMakeLists.txt and uncomment the line with test2.cpp. Do an incremental build by calling

cmake --build .

The change of CMakeLists.txt is detected but test2.cpp is NOT COMPILED! Do a second incremental build

cmake --build .

Now test2.cpp is compiled.

Delete the bugreport folder and extract it again from the ZIP file to return to the initial state. Open the CMakeLists.txt and rename the 'Notworking' target name in add_library to 'working'. Repeat all steps above and you will see that test2.cpp is compiled in the first incremental build already, as one would expect.

I tested a lot of combinations and it seems that the capital letter in front seems to be the source of the problem.
TagsNo tags attached.
Attached Fileszip file icon bugreport.zip [^] (922 bytes) 2015-09-21 10:54

 Relationships

  Notes
(0039463)
Brad King (manager)
2015-09-21 15:09

 Strange. I can reproduce this with VS 2010. I can also reproduce it with VS 2015. I also changed the CMakeLists.txt file with this patch:

 -project(NOTWORKING)
 +project(Unrelated)

to make sure the .sln file name looks nothing like any of the .vcxproj file names and it made no difference.

Running "cmake --build ." internally runs:

  msbuild ALL_BUILD.vcxproj /t:Build /p:Configuration=Debug

I can also reproduce the issue by using the msbuild invocation directly.
(0039464)
Brad King (manager)
2015-09-21 15:14

 The difference between the two behaviors appears to be the order in which ProjectReference elements appear in "ALL_BUILD.vcxproj". It works if ZERO_CHECK comes first because that is for regenerating when CMakeLists.txt files have changed.

If I rename the "Notworking" target to "ZZZ" it still starts in a capital but also works because "ZZZ" sorts after "ZERO_CHECK" while "Notworking" sorts before it.

We'll have to look at hacking the sort function to place ZERO_CHECK first among all ProjectReference elements.
(0039466)
Johannes Asal (reporter)
2015-09-22 03:48
edited on: 2015-09-22 04:07

 Now I'm even more confused. There are ProjectDependencies in the solution file which ensure that the projects are built in the correct order. The command line build should take into account those dependencies but I guess triggering ALL_BUILD.vcxproj directly circumvents this somehow. That explains why the build works fine when running it from the solution in VisualStudio. My suggestion would be to make "cmake --build" use the solution instead:

msbuild NOTWORKING.sln /t:Build /p:Configuration=Debug

This will make it figure out the dependencies by itself. I already tested it and it seems to work fine.

You might still need an alternative for building individual targets though since the solution builds the complete CMake project including all subtargets.
(0039467)
Brad King (manager)
2015-09-22 09:27

 There are reasons we do not use the .sln file to drive the build. One of them is that msbuild refuses to build a target that is not selected for default build as part of the current configuration. For example:

 add_custom_target(CustomTarget COMMAND ...) # without the ALL option

After generating the project, msbuild cannot build the target through the solution:

 > MSBuild Unrelated.sln /t:CustomTarget
 c:\...\Unrelated.sln.metaproj : error MSB4057: The target "CustomTarget" does not exist in the project. [c:\...\Unrelated.sln]

but can when naming the .vcxproj directly:

 > MSBuild CustomTarget.vcxproj
 (builds)

In the latter case MSBuild ignores the .sln altogether so ProjectReference elements are needed.
(0039468)
Brad King (manager)
2015-09-22 09:29

 Re 0015754:0039467: Additionally, the ALL_BUILD target corresponds to "make all" and so is needed as the target used for the default build. The ALL_BUILD target is created just like the example CustomTarget shown and so needs the .vcxproj file to be named directly to get it to build.
(0039469)
Johannes Asal (reporter)
2015-09-22 09:41

 That's true. But when building with "--build ." you want all targets to be built. So maybe you could use the solution in that special case? Probably I'm missing some other pitfalls in that assumption though... Anyway, I'll be fine with any solution as long as it fixes my problem ;)
(0039470)
Brad King (manager)
2015-09-22 13:05

 I've refactored the existing target ordering logic:

 VS: Refactor target ordering logic
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03bfe71a [^]

to make the fix to this issue easy:

 VS: Fix rebuild with regeneration after input CMake code change
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=40c7b461 [^]
(0039472)
Johannes Asal (reporter)
2015-09-23 03:19

 Great! Thanks a lot.
(0040417)
Robert Maynard (manager)
2016-02-01 09:10

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2015-09-21 10:54 Johannes Asal New Issue
2015-09-21 10:54 Johannes Asal File Added: bugreport.zip
2015-09-21 15:09 Brad King Note Added: 0039463
2015-09-21 15:14 Brad King Note Added: 0039464
2015-09-22 03:48 Johannes Asal Note Added: 0039466
2015-09-22 04:07 Johannes Asal Note Edited: 0039466
2015-09-22 04:07 Johannes Asal Note Edited: 0039466
2015-09-22 09:27 Brad King Note Added: 0039467
2015-09-22 09:29 Brad King Note Added: 0039468
2015-09-22 09:41 Johannes Asal Note Added: 0039469
2015-09-22 13:05 Brad King Note Added: 0039470
2015-09-22 13:05 Brad King Assigned To => Brad King
2015-09-22 13:05 Brad King Status new => resolved
2015-09-22 13:05 Brad King Resolution open => fixed
2015-09-22 13:05 Brad King Fixed in Version => CMake 3.4
2015-09-22 13:05 Brad King Target Version => CMake 3.4
2015-09-23 03:19 Johannes Asal Note Added: 0039472
2016-02-01 09:10 Robert Maynard Note Added: 0040417
2016-02-01 09:10 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team