[CMake] MSBuild and automatic project file regenation

[Michael Hertling]

On 01/10/2012 07:09 PM, Óscar Fuentes wrote:
> Michael Hertling <mhertling at online.de>
> writes:
> 
>> But aren't the issues related at least?
> 
> Dunno.
> 
>> If I understand
>> correctly, "cmake --build" invokes MSBuild which
>>
>> - loads the solution file and the project files,
>> - reinvokes CMake via the ZERO_CHECK project/target
>>   to regenerate them if CMakeLists.txt has been modified,
>> - does *not* use the regenerated ones for building, so the
>>   affected projects/targets are left inherently out-of-date.
> 
> Yep.
> 
>> Moreover, even an additional subsequent "cmake --build" command doesn't
>> rebuild; in fact, it does nothing, as though there is no dependency of
>> a project/target on its own project file.
> 
> That doesn't happen here. The next "cmake --build" works fine (cmake
> 2.8.4, VS 10)

With CMake 2.8.7 and VS 2008, I can report the following findings:

(1) Starting out from within an empty build directory: "cmake .."
    followed by "cmake --build ." configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) "cmake --build ." rebuilds the ZERO_CHECK target and, thus,
    updates the project file to reflect the changes from (2).
    However, the corresponding target is not rebuilt and,
    thus, does not reflect the changes from (2).
(4) A further "cmake --build ." does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
    David's hint, i.e. "cmake . && cmake --build .", or
    clean first, i.e. "cmake --build . --clean-first".

As I've already said previously, this seems as if there's no dependency
of the target on its own project file. Moreover, I don't understand why
rebuilding the ZERO_CHECK project and reconfiguring with "cmake ." do
obviously have different results - the latter makes "cmake --build ."
rebuild, the former doesn't. If I understand correctly, the purpose of
ZERO_CHECK is to rerun CMake in order to update the project files, so
the "cmake --build ." from (4) - at the lastest - should rebuild the
affected targets.

>> AFAICS for now, it's solely
>> David's hint, i.e. "cmake . && cmake --build .", that results in the
>> project being actually rebuilt after CMakeLists.txt has changed,
>> unless one uses the "--clean-first" option.
>>
>>>> If so, I would strongly support a feature request in
>>>> this respect since, IMO, it's actually quite confusing that CMake's
>>>> "--build" command does anything but rebuilding.
>>>
>>> I agree.
>>
>> Do you file a feature request / bug report?
> 
> Nope.
> 
>> Personally, I'd like to be
>> sure that after a "cmake --build" command, everything is up-to-date as
>> it is with Makefiles, provided it can be realized with MSBuild at all.
> 
> Obviously, how MSBuild works when the project files are regenerated on
> the fly is a bug. I have no idea about how hard is to fix it, though.
> 
>> Try <http://www.cmake.org/pipermail/cmake/2011-November/047802.html>.
> 
> Hmmm... After reading your example, I can't say for sure that when
> `cmake --build' worked the second time here it didn't cointain changes
> on the source files too.
> 
> CMake with VS 10 and/or MSBuild is pesky, apart from the problems
> MSBuild has on its own. I'm looking at using other generators that
> support parallel builds. JOM is not truly parallel (it only builds a
> toplevel target at once). Ninja looks like the right thing, but doesn't
> work on MS Windows.

Perhaps, David Cole can give us some enlightenment; since he used to
work for MS, he certainly has some intimate insights into the Visual
World. ;-) Anyway, this issue is no catastrophe, provided one knows
the trick with "cmake . && cmake --build .", but it is annoying and
error-prone; usually, I'd expect that after "cmake --build", every-
thing is up-to-date. BTW, does "cmake --build" work correctly in
this regard with other non-Makefile generators, notably XCode?

Regards,

Michael