|
Notes |
|
|
(0024376)
|
|
David Cole
|
|
2011-01-03 18:38
|
|
I do not have a problem with VS 2008 -- do you have specific steps to reproduce?
I am working on a script to demonstrate that the macro we have that works with VS2008 does not work with VS2010. I'll be submitting this to MS shortly, and will also attach a copy of that script (Windows *.cmd file) to the related issue 0011258 about VS2010.
Please provide steps (or better yet, a script!) to show the problem if possible.
Thanks. |
|
|
|
(0024426)
|
|
James Bigler
|
2011-01-05 11:59
(edited on: 2011-01-05 17:14) |
|
I'll if I can reliably reproduce it. It seems to happen ~ 50% of the time.
|
|
|
|
(0024442)
|
|
David Cole
|
|
2011-01-05 17:17
|
|
I am unsetting the "target version" field and claiming that there is not enough time to address this issue before the 2.8.4 release at this point.
If steps to reproduce, even ~ 50% of the time, are presented before Mon. Jan. 10 *and* they do reproduce here on a machine for me, *and* there is a fix that seems reasonable, ... I will re-target this for 2.8.4 again at that point.
Otherwise, a fix for this will have to be deferred to a future release, as it becomes available. |
|
|
|
(0024479)
|
|
James Bigler
|
|
2011-01-06 15:31
|
|
I just spent an hour or so trying to reproduce this in a build that isn't our production software and you could get access to. Unfortunately I couldn't make it trigger. I'll try and keep a closer eye on it to see what happens to trigger it in my production build.
One thing to note is that in my production build, frequently during the middle of the build (i.e. the there are still projects compiling, but others have finished), CMake configures again and triggers the plugin. Have you ever seen this behavior where the plugin gets triggered during or at the end of a build instead of at the next build? |
|
|
|
(0024492)
|
|
David Cole
|
|
2011-01-06 16:44
|
|
So...... if there's something in your build process that is triggering a CMake re-run in the middle of a build, that is suspicious right there.
The inputs to CMake should probably not be changed during the scope of a Visual Studio based build.
Think about it: it's already a system wherein:
- Visual Studio thinks it's in charge -- once you click the build button, it does not expect it's solution and project files to change out from under it before the build is done...
- CMake comes along and says, no, I'm in charge, important stuff has changed and now I'm going to re-run, and change the sln and vcproj files out from under VS, and then expect it to re-load and start over...
- Now, what you're telling me is, no, CMake's not really in charge, in fact, some custom build step that you've added actually is *really* in charge, changing a CMake input in the middle of the build and then expecting *CMake* to re-run again, and then VS has to re-load again, ...
I'm starting to feel stuck in an infinite loop just talking about it. Tell me there's a stop condition in here somewhere.
:-)
Do you do any "file(GLOB" (or other) script generation based on disk contents, perhaps? And are any of those results included into a CMakeLists.txt file?
If so, one way to workaround this might be to put that stuff off to the very last project/target built, using add_dependencies to force it last if necessary, and then at least input does not change until the end of the build. Then you just have to keep building until nothing changes.
I'll stop now. This is all speculative anyhow until you narrow it down on your side. Just thought I'd maybe give you some ideas for what to look for by going on a mini-rant.
More to come, I'm sure... ;-) |
|
|
|
(0024543)
|
|
David Cole
|
|
2011-01-10 14:06
|
|
|
Please see note on related bug 0011258:0024541 which describes a new approach to solving this problem that we are thinking of doing... Leave comments there if you have any. Thanks. |
|
|
|
(0026905)
|
|
James Bigler
|
|
2011-06-17 18:02
|
|
Well, I do have more information about why it was reconfiguring in the middle a build. This has to do with how the project has a dependency on the CMakeLists.txt file. If there is more than one project in the list, then you can have problems with parallel builds that both have build targets on the *same* CMakeLists.txt file. If project A runs and generates a file used by the configuration process (such as a dependency list generated by FindCUDA), then the next project that comes along that has the same CMakeLists.txt file will see that the CMakeLists.txt build rule needs to run and causes a reconfigure during build.
The solution that I talked with David (I believe) was to remove the explicit rule on the CMakeLists.txt file and make all the projects depend on the ZERO_CHECK target. This will help the parallel builds behave more properly, but still provide a way to get the configure going when needed. |
|
|
|
(0030609)
|
|
David Cole
|
|
2012-08-13 15:16
|
|
Sending old, not-recently-updated issues to the backlog.
(The age of the bug alone means that nobody is actively working on it...)
If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]
It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
|
|
|
|
(0041763)
|
|
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. |
|