[CMake] complete rebuild

David Cole david.cole at kitware.com
Thu Dec 30 15:38:25 EST 2010 

When I waited until after 11:54 am, and ran this just now, I got a
full build the first time, and then a "do nothing" incremental rebuild
the 2nd time.

So I guess this is a case of "works for me" -- there's something odd
about your machine or environment...? Has anybody else experienced
anything like this?

Hopefully, there's a logical explanation for what you're seeing, as
opposed to something being completely broken.

Cheers,
David


Here is the output from my 2nd build, which only took 0.25 seconds to
complete, and compiled nothing:

C:\Users\davidcole\Dashboards\My Tests\DependencyBug>msbuild DepBug.sln
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 12/30/2010 3:33:14 PM.
Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\DepBug.sln" on node 1 (default targets).
ValidateSolutionConfiguration:
  Building solution configuration "Debug|Win32".
ValidateProjects:
  The project "ALL_BUILD" is not selected for building in solution
configuration "Debug|Win32".
Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\DepBug.sln" (1) is building
"C:\Users\davidcole\Dashboard
s\My Tests\DependencyBug\ZERO_CHECK.vcxproj" (2) on node 1 (default targets).
InitializeBuildStatus:
  Creating "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild"
because "AlwaysCreate" was specified.
CustomBuild:
  All outputs are up-to-date.
FinalizeBuildStatus:
  Deleting file "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild".
  Touching "Win32\Debug\ZERO_CHECK\ZERO_CHECK.lastbuildstate".
Done Building Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\ZERO_CHECK.vcxproj" (default targets).

Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\DepBug.sln" (1) is building
"C:\Users\davidcole\Dashboard
s\My Tests\DependencyBug\build\DepBug\depBug.vcxproj.metaproj" (3) on
node 1 (default targets).
Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\build\DepBug\depBug.vcxproj.metaproj" (3) is
building "C:
\Users\davidcole\Dashboards\My
Tests\DependencyBug\build\DepBug\depBug.vcxproj" (4) on node 1
(default targets).
Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\build\DepBug\depBug.vcxproj" (4) is building
"C:\Users\da
vidcole\Dashboards\My Tests\DependencyBug\ZERO_CHECK.vcxproj" (2:3) on
node 1 (default targets).
InitializeBuildStatus:
  Creating "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild"
because "AlwaysCreate" was specified.
CustomBuild:
  All outputs are up-to-date.
FinalizeBuildStatus:
  Deleting file "Win32\Debug\ZERO_CHECK\ZERO_CHECK.unsuccessfulbuild".
  Touching "Win32\Debug\ZERO_CHECK\ZERO_CHECK.lastbuildstate".
Done Building Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\ZERO_CHECK.vcxproj" (default targets).

InitializeBuildStatus:
  Creating "depBug.dir\Debug\depBug.unsuccessfulbuild" because
"AlwaysCreate" was specified.
CustomBuild:
  All outputs are up-to-date.
ClCompile:
  All outputs are up-to-date.
ManifestResourceCompile:
  All outputs are up-to-date.
Link:
  All outputs are up-to-date.
Manifest:
  All outputs are up-to-date.
FinalizeBuildStatus:
  Deleting file "depBug.dir\Debug\depBug.unsuccessfulbuild".
  Touching "depBug.dir\Debug\depBug.lastbuildstate".
Done Building Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\build\DepBug\depBug.vcxproj" (default targe
ts).

Done Building Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\build\DepBug\depBug.vcxproj.metaproj" (defa
ult targets).

Done Building Project "C:\Users\davidcole\Dashboards\My
Tests\DependencyBug\DepBug.sln" (default targets).


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.25


(And, thankfully, I get the same "do nothing" output when I run "cmake
--build . --config Debug" ...)



On Thu, Dec 30, 2010 at 9:52 AM, Anders Backman <andersb at cs.umu.se> wrote:
> Eh?
> The files looks ok to me (in Sweden :-)
> We are ahead of US (in time also :-) , but that shouldn't matter in this
> case.
> I unpacked the file, looked at the dates, and they are all from today around
> noon (11:54).
> Which means either you have to wait until after 11:54 or you have to touch
> the files...
> I can certainly touch and make a double check...
> Ok. touched all files, ran cmake . and then:
> cmake --build . --config Release
> Everything is built for each time I execute the above command. So problem
> resists.
>
> /A
> On Thu, Dec 30, 2010 at 3:29 PM, David Cole <david.cole at kitware.com> wrote:
>>
>> The rar file you have pointed us to, when extracted, yields "modified
>> time" stamps on the source files in the future. No matter how many
>> times you rebuild such a project, you will always get rebuild problems
>> with systems that base "modified-ness" on time stamps. Visual Studio /
>> msbuild is such a system (as are most makes).
>>
>> The question is: why *doesn't* this happen with VS 2008 on the same
>> source tree? It should... The CMakeLists.txt file is in the future as
>> are most of the referenced c++ source files.
>>
>> Where did these source files from the future come from? (A colleague
>> in another time zone, a computer with a clock problem, or did you do
>> this on your laptop in another time zone and then adjust the time
>> later and then try the build (travelling lately? :-) ... ) ??
>>
>> Please fix up the mod times, try again, and let us know if you still
>> have problems.
>>
>>
>> Also, just as an FYI, here's the reply I was working on before I
>> discovered the time stamp madness:
>>
>> You can use:
>> cmake --build . --config Release
>>
>> to build a CMake-based project via the command line regardless of the
>> underlying native build system. And when you do, it will generate the
>> "correct" call to that underlying native build system, whether it be
>> make, devenv, msbuild or xcode.
>>
>> In the Visual Studio 10 case, the CMakeCache should have something
>> like this defined:
>>
>> MAKECOMMAND:STRING=C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
>> ALL_BUILD.vcxproj /p:Configuration=${CTEST_CONFIGURATION_TYPE}
>>
>> In which case, that is the command line executed by a call to "cmake
>> --build"
>>
>> MSBuild does not need the sln file, it can build the whole project
>> based on ALL_BUILD.vcxproj and the other vcxproj files that it
>> references. The sln file is only needed by Visual Studio.
>>
>>
>> HTH,
>> David
>>
>>
>> On Thu, Dec 30, 2010 at 6:06 AM, Anders Backman <andersb at cs.umu.se> wrote:
>> > I think I managed to reproduce the problem, partially.
>> > The file below contains a project which for me reproduces the problem
>> > when I
>> > use msbuild.
>> > F7 (Build->BuildSolution) works (builds only once, then next time, it
>> > does
>> > nothing).
>> > So there is something in the combination of CMake and msbuild which
>> > causes
>> > the problem.
>> > We use Incredibuild, which uses msbuild, hence we get the problem also
>> > in
>> > Incredibuild.
>> > I do not know the difference between F7 and msbuild though.
>> > http://rapidshare.com/files/439941435/DependencyBug.rar
>> > Instructions:
>> > 1. Unpack dep2.rar into a new empty directory
>> > 2. install CMake (2.8.2 or later)
>> > http://www.cmake.org/files/v2.8/cmake-2.8.3-win32-x86.exe
>> > 3 go to the directory in a command prompt
>> > 4. execute: cmake .
>> > 5. msbuild DepBug.sln
>> > 6. msbuild DepBug.sln << Builds everything again from scratch.
>> >
>> > /A
>> > On Wed, Dec 29, 2010 at 1:26 PM, Anders Backman <andersb at cs.umu.se>
>> > wrote:
>> >>
>> >> Ok, Im already using the nightly build (from Tuesday I believe), as I
>> >> discovered a bug in CMake yesterday.
>> >> I will bug M$ too :-)
>> >> /A
>> >>
>> >> On Wed, Dec 29, 2010 at 1:03 PM, David Cole <david.cole at kitware.com>
>> >> wrote:
>> >>>
>> >>> For Visual Studio generators, CMake does *NO* depedency analysis. It
>> >>> generates solution and project files such that Visual Studio can do
>> >>> all the dependency analysis and decide what to re-build when files
>> >>> change.
>> >>>
>> >>> My advice to you would be:
>> >>> - use only CMake 2.8.3 or newer (a nightly development build of CMake)
>> >>> with Visual Studio 10 -- CMake 2.8.2 and earlier had significant bugs
>> >>> related to VS10 that have since been resolved...
>> >>> - using a newer CMake, isolate the problem to a minimally reproducible
>> >>> case and then report a bug in the bug tracker about it including the
>> >>> steps to reproduce the problem
>> >>>
>> >>> Reply here again and point us to the bug.
>> >>>
>> >>>
>> >>> HTH,
>> >>> David
>> >>>
>> >>>
>> >>> On Wed, Dec 29, 2010 at 4:07 AM, Anders Backman <andersb at cs.umu.se>
>> >>> wrote:
>> >>> > Hi all.
>> >>> > I have a problem where I have a project of C++ headers and source
>> >>> > files
>> >>> > which are built into a .lib .dll.
>> >>> > Now this works just fine with CMake 2.8.x and VisualStudio 2008.
>> >>> > I press F7 everything builds. I press F7 again, it is all built,
>> >>> > nothing to
>> >>> > be done.
>> >>> > But now when I move over to vs2010, I get into problems where no
>> >>> > matter
>> >>> > how
>> >>> > I build the project, it constantly want to rebuild everything.
>> >>> > I have tried both 'msbuild project.sln' from the command line, as
>> >>> > well
>> >>> > as
>> >>> > build (F7) inside of VisualStudio  as well as using Incredibuild.
>> >>> > The
>> >>> > result
>> >>> > is the same. If I press F7, it builds everything as it was not built
>> >>> > before.
>> >>> > I did some googling on the issue, and some suggest that there is a
>> >>> > file
>> >>> > in
>> >>> > the project (header) which does not exist on disk, causing the
>> >>> > problem.
>> >>> > We do file(glob) on all files, so a file which is not found, should
>> >>> > not
>> >>> > be
>> >>> > part of the project.
>> >>> > Right now, it seems to be hard to reduce the problem. When I start
>> >>> > from
>> >>> > the
>> >>> > full project, 107 files, it want to rebuild everything.
>> >>> > When I reduce the problem, I can get down to one single file, still
>> >>> > it
>> >>> > wants
>> >>> > to build it. Its a c file, and there is nothing special about it. I
>> >>> > even
>> >>> > managed to reduce that down to one function, no includes. still the
>> >>> > same
>> >>> > problem.
>> >>> > If I copy the relevant files (a few cmakelists.txt and the directory
>> >>> > structure, including the two files (.h .c) it builds as it should
>> >>> > again.
>> >>> > I tried to run cmake and generate vs2008 files, that works. Open
>> >>> > them
>> >>> > in
>> >>> > vs2010, build, then that works (with the two files only).
>> >>> >
>> >>> > So anyway, before I put you all to sleep, as far as I know, there
>> >>> > are
>> >>> > two
>> >>> > dependency parsers involved here:
>> >>> > - CMake runs through source files and generates dependencies, right?
>> >>> > - THen visual studio does the same (generating the External
>> >>> > dependencies
>> >>> > folder in the project). Now there is SOMETHING wrong in either one,
>> >>> > or
>> >>> > both
>> >>> > or none related to VS2010.
>> >>> > Does someone have any hints on how to debug this problem? I have
>> >>> > spent
>> >>> > substantial time, and I cant seem to get anywhere.
>> >>> > I cant reduce it to something I can post on the list, as it just
>> >>> > magically
>> >>> > works when I want to rip it out.
>> >>> > At one point, I had 3 cmakelists, each with about 3 lines. 2 source
>> >>> > files
>> >>> > (.h .c), I did clean on CMakeCache.txt between each cmake . run,
>> >>> > loaded
>> >>> > the
>> >>> > project build and got the error. Fairly simple scene. But as soon as
>> >>> > I
>> >>> > try
>> >>> > to move that to another dir, it fails.
>> >>> > Thankful for any advice on the matter.
>> >>> >
>> >>> > --
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > 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
>> >>> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >
>> >
>> >
>> > --
>> > __________________________________________
>> > Anders Backman, CTO  Algoryx Simulation AB
>> > Uminova Science Park, Box 7973,  SE-907 19
>> > Umeå,  Sweden
>> > anders at algoryx.se http://www.algoryx.se
>> > Cell: +46-70-392 64 67
>> >
>> > _______________________________________________
>> > 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
>> >
>
>
>
> --
> __________________________________________
> Anders Backman, CTO  Algoryx Simulation AB
> Uminova Science Park, Box 7973,  SE-907 19
> Umeå,  Sweden
> anders at algoryx.se http://www.algoryx.se
> Cell: +46-70-392 64 67
>

More information about the CMake mailing list