[CMake] complete rebuild

Thu Dec 30 09:29:47 EST 2010

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
>