> The only race was for multiple processes simultaneously deciding they need
to create the (currently missing) file and then trying to open the file for
> write at the same time.
To what I see on the logs, this is not what I observe:
build 26-avr.-2013 13:11:12 CMake does not need to re-run because
XXX\tmp\src\YYYY\CMakeFiles\generate.stamp is up-to-date.
build 26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt
build 26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt
build 26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt
build 26-avr.-2013 13:11:12 CMake does not need to re-run because
XXX\tmp\src\YYYY\CMakeFiles\generate.stamp is up-to-date.
then
build 26-avr.-2013 13:11:24 Building Custom Rule CCC/CMakeLists.txt
build 26-avr.-2013 13:11:24 CUSTOMBUILD : CMake error : Cannot restore
timestamp XXX\tmp\src\YYYY\CMakeFiles\generate.stamp
[XXX\tmp\src\YYYY\SSS.vcxproj]
The file XXX\tmp\src\YYYY\CMakeFiles\generate.stamp already existed long
before the error, and many projects were built between. But if by "missing"
you are saying that it is missing because moved to another filename (I am a
bit ignorant of how it works), then we still have a race condition.
> CMake has a different meaning for "project" than .vcxproj so this will
still be the same name for all targets in a directory.
> Each .vcxproj file corresponds to what CMake calls a "target".
Indeed, sorry for that mistake.
> That race is gone because replacement is now atomic
This is true for unices, but does not seem to be true on Windows. There is a
fallback that tries to move the file 5 times before triggering an error.
This is not atomic.
> In order to use a different stamp file for each .vcxproj file then the
custom command produced by CreateVCProjBuildRule would not be able to be
> re-used across multiple targets. Instead each generator would have to
hand-code the custom command for its own .vcxproj file.
> While possible it is a lot of work and this bug has already been solved.
True, and more true now I have a closer look at the code. I do not
understand why it was so (historically), and not understanding that does not
help me to provide you a patch. For instance, in "
cmLocalVisualStudio10Generator::Generate()", all vcxproj are generated, and
then one unique timestamp file is written, hence for the current
CMakeLists.txt. If I understand well, this is the only location (VC10) where
the timestamp is written/made dirty.
"cmLocalVisualStudio7Generator::CreateVCProjBuildRule()" adds a rule for
checking the timestamp, but I do not understand why this is not a per-target
custom build rule in "cmLocalVisualStudio7Generator::AddCMakeListsRules()"
(this could easily be done in cmLocalVisualStudio10Generator::Generate()),
nor to what entity the " this->Makefile->AddCustomCommandToOutput" (in
"cmLocalVisualStudio7Generator::CreateVCProjBuildRule()" ) refers to.
But if we have something like:
void cmLocalVisualStudio7Generator::AddCMakeListsRules()
{
cmTargets &tgts = this->Makefile->GetTargets();
// Create the regeneration custom rule.
if(!this->Makefile->IsOn("CMAKE_SUPPRESS_REGENERATION"))
{
// HERE: just returning the files that should be included
if(cmSourceFile* sf = this->Get_CMAKELISTFILENAME())
{
// Add the rule to targets that need it.
for(cmTargets::iterator l = tgts.begin(); l != tgts.end(); ++l)
{
if(l->first != CMAKE_CHECK_BUILD_SYSTEM_TARGET)
{
l->second.AddSourceFile(sf);
// HERE adding the custom build rule checking the timestamps
l->ADD_CUSTOM_BUILD_RULE_WITH_STAMPS();
}
}}}}
this should be closer to what I thought initially.
For an automatic build daemon, I think setting CMAKE_SUPPRESS_REGENERATION
should be sufficient workaround (until the next "true" release with the
proposed workaround).
Best,
Raffi Enficiaud
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
