|
Notes |
|
|
(0032222)
|
|
Brad King
|
|
2013-02-08 09:40
|
|
I can reproduce this:
In the build tree, look at the directory "Win32/Debug/ItShouldBeAlwaysBuilt" maintained by the IDE. Look at the presence and timestamps of files in that directory at each step during your instructions. When running with Ctrl-F5 I see a dialog pop up that warns certain projects are not up to date. The answer chosen does not seem to matter for this problem. Either way a file ends up in this IDE directory that prevents it from building the target again later. Removing the file or pressing Crtl-Alt-F7 again resolve the state and allow it to build again.
I do not know if there is anything CMake can do about this. Is it possible to adjust any settings inside the IDE to make it behave as desired? |
|
|
|
(0032226)
|
|
Hauke Heibel
|
|
2013-02-08 10:55
|
|
Hi Brad, I was not able to identify the file you have described. I created a more complete example which shows the same behavior. In particular, the new example does not result in any errors, when pressing Ctrl-F5 - assuming the target "OutOfDate" is marked as the startup project in the solution since it is the one containing the executable.
I will investigate further and get back with results once I have them. |
|
|
|
(0032231)
|
|
Brad King
|
|
2013-02-08 13:55
|
|
|
Thanks for investigating. FYI, by "settings inside the IDE" I meant a project-level setting that one can change when creating a project through the IDE by hand, not an IDE-wide setting. If it is not possible to achieve by hand then I do not think CMake can do much except document the expectation. |
|
|
|
(0032235)
|
|
Hauke Heibel
|
|
2013-02-08 14:52
|
|
Well, it does not look good at all. I have no idea what's preventing the re-build. Even the debug output of visual studio's build environment is not helping because in the case in which the custom target is not built, there is no debug output at all. No matter to which value I have set the debug level under 'Tools -> Options -> Projects and solutions -> Build and run -> MSBuild project build output verbosity'.
Maybe I have to consult the MS forums in order to find a project-level setting which fixes this problem or maybe I found a bug in the IDE. |
|
|
|
(0032237)
|
|
Brad King
|
|
2013-02-08 15:09
|
|
Re 0013900:0032235: Thanks for reporting back. Moving to backlog awaiting a way to tell the IDE about this.
If you go to MS forums, please try to construct a test case/project by hand without involving CMake and post that one instead. That will be simpler for them to reproduce.
|
|
|
|
(0032382)
|
|
Hauke Heibel
|
|
2013-02-26 04:41
|
|
|
|
|
(0032710)
|
|
Hauke Heibel
|
|
2013-03-27 13:59
|
|
Hi again, it seems as if the issue will remain for a quite some time. Maybe up-voting the corresponding bug report (according to MS mine was a dupe) helps:
https://connect.microsoft.com/VisualStudio/feedback/details/769495/custombuild-tool-not-building-properly-on-incremental-build [^]
The thing is that we just found out today, that the implications are worse than we expected. It turns out that auto-mocing Qt headers is broken due to this issue. The custom targets Foo_automoc CMake generates must be manually build when modifying any signals or slots of Qt headers in the project Foo.
An unfortunate workaround might be to fall back to pre-build events for the Qt header files. |
|
|
|
(0032718)
|
|
Brad King
|
|
2013-03-28 10:17
|
|
Re 0013900:0032710: Thanks for reporting back. I'm glad it will be fixed in the next VS but we'll still have to deal with it in VS 11 :(
Do you propose to replace use of the Foo_automoc target with a PRE_BUILD event in the Foo target? I don't think that will run if Foo is up to date. |
|
|
|
(0032720)
|
|
Hauke Heibel
|
|
2013-03-28 10:50
|
|
Yes, this is pretty much what I had in mind. As far as I see it it should work because Foo must be rebuild when one of its headers changes. So the pre-build event should be guaranteed to be running once a header file is changed. Actually this would even be true for header files which do not require moc'ing or uic'ing.
IIRC, it used to be possible to define per file pre-build events (as opposed to per project). If this were still be possible one could add the moc and uic commands to the files which need them only. I think this is what we did before switching to automoc'ing.
Maybe I find some time later on to check, whether per file pre-build events are still supported for h/cpp files. |
|
|
|
(0032721)
|
|
Brad King
|
|
2013-03-28 11:06
|
|
Re 0013900:0032720: Ahh, that makes sense.
Please read this note from the documentation of PRE_BUILD:
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#command:add_custom_command [^]
"Note that the PRE_BUILD option is only supported on Visual Studio 7 or later.
For all other generators PRE_BUILD will be treated as PRE_LINK."
Therefore I think we should use this workaround only for VS 11 so that automoc works consistently on other generators.
Take a look at cmQtAutomoc.cxx in our 'master' branch to work on the code for this. Currently the "makefile->AddUtilityCommand(...)" call creates the automoc target. |
|
|
|
(0032723)
|
|
Hauke Heibel
|
|
2013-03-29 13:08
|
|
|
Hi, I've added a patch. I will do some more testing with it soon but it seems to be working. In fact, I think this is even nicer than before since it reduces the number of targets and thus the loading time of solutions. |
|
|
|
(0032724)
|
|
Hauke Heibel
|
|
2013-03-29 13:44
|
|
|
I updated the patch since it is clearly not fixing this issue, but the automoc'ing for VS11 which failed due to this issue. |
|
|
|
(0032725)
|
|
Brad King
|
|
2013-03-29 13:50
|
|
|
Re 0013900:0032724: Thanks for the patch. As you point out in 0013900:0032723 the generated solutions are nicer. Therefore I think we should use this for all VS >= 7. I've generalized the patch for that and will post it back here for you to try out once I've verified it works. |
|
|
|
(0032729)
|
|
Brad King
|
|
2013-03-29 16:07
|
|
Please try "969a7fde+0001-automoc-Use-a-pre-build-event-in-VS-7.patch" on top of commit 969a7fde from CMake's master branch.
It took a bit more work because the QtAutomoc test uncovered the use case of automoc with an OBJECT library, and normally OBJECT library targets do not support PRE_BUILD events. |
|
|
|
(0032731)
|
|
Hauke Heibel
|
2013-03-30 07:26
(edited on: 2013-03-30 07:52) |
|
Hi Brad, your patch looks good. I've just build a large solution with about 10 Qt projects including .qrc, .ui and Qt .h files. Everything worked nicely. Thanks for your support in fixing the moc'ing.
|
|
|
|
(0032735)
|
|
Brad King
|
|
2013-04-01 10:00
|
|
|
|
|
(0032769)
|
|
Brad King
|
|
2013-04-05 15:24
|
|
For reference, I just tested the original issue (just as in 0013900:0032222) with VS 2012 Update 2:
Version 11.0.60315.01 Update 2
and it still occurs. |
|
|
|
(0032770)
|
|
Hauke Heibel
|
|
2013-04-05 15:34
|
|
|
This is unfortunately expected because the support said that no fix is to be expected in a CTP. The fix will only be available in the next major version, maybe VS 2014. |
|
|
|
(0032853)
|
|
AllenPestaluky
|
2013-04-16 17:28
(edited on: 2013-04-16 17:30) |
|
Re 0013900:0032735: I don't think the fix that was applied on March 29 actually worked around the issue... I am using nightly cmake version 2.8.10.20130414-g2011fa and I still have what I think is the same issue.
I am attaching the zip "AllenPestaluky_add_custom_target_Visual_Studio_11_bug.zip" which exhibits the problem even with the new nightly builds, which I believe have the patch applied.
These are the steps to reproduce:
- cmake -G "Visual Studio 11"
- Open sln in Visual Studio 2012 Express for Windows Desktop
- Build project any number of times using F6: The custom target is always built as expected
- Debug project using F5: The custom target is NOT built: The custom target is treated as if it was already up to date!
- Debug project or build project any number of times using F5 or F6: The custom target is never built again until you clean it manually!
Am I wrong in thinking that the patch should be applied to version 2.8.10.20130414-g2011fa? Or am I dealing with another issue?
Thanks!
|
|
|
|
(0032854)
|
|
Hauke Heibel
|
|
2013-04-17 03:12
|
|
Re 0013900:0032853: Hi Allen, you are dealing with the issue reported here.
The fix applied on March 29th does not workaround this isssue in general. It is "only" a workaround for the side effect that the AUTOMOC feature did not work correctly since it was depending on add_custom_target. |
|
|
|
(0032889)
|
|
AllenPestaluky
|
2013-04-17 08:59
(edited on: 2013-04-17 09:45) |
|
Ah, I see: I wasn't clear on what AUTOMOC was. Thanks for explaining that!
Setting a fake output on the "custom build step" in VS 11 seems to still work fine (most of the time?) when I set commands inside the command line field: there's no way mapping to this through cmake, is there?
|
|
|
|
(0032893)
|
|
Brad King
|
|
2013-04-17 10:18
|
|
Re 0013900:0032889: So a custom command output that is not actually created by the rule convinces VS 11 to always run it even with this bug? We could teach CMake to generate this for VS 11 add_custom_target rules.
If you have a "fake" add_custom_command OUTPUT you can mark the source with the SYMBOLIC property:
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_sf:SYMBOLIC [^]
and CMake will tell the generated build system (if necessary) not to expect the file to actually be produced by the custom command. |
|
|
|
(0032899)
|
|
AllenPestaluky
|
|
2013-04-17 10:43
|
|
|
|
|
(0032900)
|
|
AllenPestaluky
|
|
2013-04-17 11:05
|
|
Actually, from my tests, simply replacing the CustomBuild tags with CustomBuildStep tags in the generated vcxproj for the custom target fixes it. (http://msdn.microsoft.com/en-us/library/dd293663.aspx [^])
The problem seems to be with CustomBuild but does not affect CustomBuildStep.
As a side note, I beleive that Cmake was using the fake output trick anyway, but it seems to be broken when you use a CustomBuild instead of a CustomBuildStep.
Is this making any sense? |
|
|
|
(0032905)
|
|
Brad King
|
|
2013-04-18 09:34
|
|
Re 0013900:0032900: Thanks for your investigation and report.
When I visit a source property page in the IDE and follow
Configuration Properties -> General -> Item Type
the drop-down has "Custom Build Tool" but not "Custom Build Step". If I hack the project file in an external editor to use "<CustomBuildStep>" then the IDE reports it in the property page as "CustomBuildStep" though it is still not in the drop-down.
See attachment 0001-WIP-Try-VS-CustomBuildStep-instead-of-CustomBuild-13.patch which tries to switch from CustomBuild to CustomBuildStep in general. Many tests pass with this change, but not all. In particular CMake's BuildDepends test fails because it does not appear that CustomBuildStep actually gets updated during an incremental rebuild. I'm not sure what's wrong with it; that will take more investigation.
Another possibility is to use CustomBuildStep only for the add_custom_target "always out of date" rules originally reported in this issue. However, that will just be another subset of the cases where this VS 11 bug triggers.
I'm not sure when I'll have time to investigate further. |
|
|
|
(0032907)
|
|
AllenPestaluky
|
2013-04-18 14:54
(edited on: 2013-04-22 13:50) |
|
I also noticed that the Custom Build Step was not appearing on CMake-generated projects. I was also confused at how the CMake-generated Custom Build Tool details were not appearing in the "Command Line", "Outputs", and "Additional Dependencies" fields of the pages in the Visual Studio GUI under the Configuration Properties.
...So I compared what CMake was generating and what Visual Studio generates when you create a new project and discovered the following:
The Visual Studio-generated project has the <CustomBuild> and <CustomBuildStep> elements inside of a <ItemDefinitionGroup> element while the CMake-generated project has them inside of a regular <ItemGroup>.
EDIT: Originally, I thought that moving the <CustomBuild> element inside of the <ItemDefinitionGroup> element of the matching configuration and discarding the Include attribute fixed the problem and made the details show up correctly in the GUI... The GUI definitely shows the elements inside of <ItemDefinitionGroup>, but it does not fix the problem.
So maybe this problem is specifically related to <CustomBuild> elements outside of <ItemDefinitionGroup> elements. Moving the <CustomBuild> elements into the <ItemDefinitionGroup> of the matching configuration might be a larger change, but because of how the Visual Studio GUI responds positively to it, it might be the "correct" way to construct <CustomBuild> elements and fix this problem...
|
|
|
|
(0032908)
|
|
Brad King
|
|
2013-04-18 16:15
|
|
|
Re 0013900:0032907: Where in the IDE can I browse to members of an ItemDefinitionGroup? Without Include="" the rules do not appear to be attached to any sources. |
|
|
|
(0032909)
|
|
Brad King
|
|
2013-04-18 16:16
|
|
|
Re 0013900:0032908: Can you attach a file generated by CMake and another version that you've edited to look like you propose? |
|
|
|
(0032911)
|
|
Brad King
|
|
2013-04-19 08:38
|
|
Relevant documentation:
Understanding Custom Build Steps and Build Events
http://msdn.microsoft.com/en-us/library/e85wte0k.aspx [^]
How to: Add a Custom Build Step to MSBuild Projects
http://msdn.microsoft.com/en-us/library/dd293663.aspx [^]
How to: Add Custom Build Tools to MSBuild Projects
http://msdn.microsoft.com/en-us/library/dd293705.aspx [^]
From the top link:
A custom build step is a build rule associated with a project.
...
A custom build tool is a build rule associated with one or more files.
...
Build events and custom build steps run in the following order along with other build steps:
Pre-Build event
Custom build tools on individual files
MIDL
Resource compiler
The C/C++ compiler
Pre-Link event
Linker or Librarian (as appropriate)
Manifest Tool
BSCMake
Custom build step on the project
Post-Build event
In the case of add_custom_command CMake expects them to run before compilation so that they can generate sources. They are also associated with specific files (MAIN_DEPENDENCY or OUTPUT ".rule" file). Therefore the "Custom Build Tool" is the correct choice for them.
We might be able to switch to a "Custom Build Step" for the add_custom_target's COMMAND (the "always out of date" one), but its DEPENDS refer to add_custom_command's OUTPUT(s) and so those must still each be a "Custom Build Tool". |
|
|
|
(0032922)
|
|
AllenPestaluky
|
|
2013-04-22 14:16
|
|
My appologies: It appears that my last comment regarding the differences between the <ItemDefinitionGroup> and <ItemGroup> only have an impact on the GUI but do not have an impact on the behaviour. I have edited the note to reflect this.
I would request that add_custom_target be represented in a <CustomBuildStep> rather than a <CustomBuild>. This means no include file, but if I understand correctly, the included .rule include file is always empty for the add_custom_target. (please correct me if I'm wrong)
I see that this won't fix all of the problem because DEPENDS may refer to the result of a <CustomBuild> -- Are there any situations where a DEPEND isn't generated at all (rather than just being out of date) because of the <CustomBuild> bug? If the DEPEND is at least there, then running the add_custom_target on an out-of-date DEPEND is better than not running it at all (it would fix my problem anyway, as I have no DEPENDS).
Thanks for your prompt replies! |
|
|
|
(0034190)
|
|
AllenPestaluky
|
|
2013-10-21 10:20
|
|
|
I have been unable to reproduce this issue in Visual Studio 12 (2013) Express for Windows Desktop. It appears that it has been fixed with the new visual studio... |
|
|
|
(0038798)
|
|
Nick D'Ademo
|
|
2015-05-26 06:22
|
|
I just tried to reproduce this issue with the attached "more_complete_example.zip" file and the "Visual Studio 11 2012" generator.
- CMake v3.2.2
- Visual Studio 2012 (v11.0.61030.00 Update 4)
Issue still exists unfortunately.
Behavior is exactly as originally described in issue:
* Hit Ctrl-Alt-F7 in the IDE and the expected message is printed.
* Hit F7 (even multiple times) and the expected message is printed.
* Hit Ctrl-F5 and skip the error message (it is not important for this issue), hit again F7. No message will be printed besides that all targets are up-to date.
* Even directly building the target via its context menu does not result in an actual build anymore once Ctrl-F5 (or F5) was used.
So it seems that something is broken in the build process when running the application (via F5 or Ctrl-F5). |
|
|
|
(0042220)
|
|
Kitware Robot
|
|
2016-06-10 14:28
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
CMakeLists.txt (214) 2013-02-08 07:26
more_complete_example.zip (599) 2013-02-08 10:45