[Pkg-cmake-team] Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Brad King]

On 04/24/2016 11:59 AM, Andreas Beckmann wrote:
> On Thu, 7 Apr 2016 14:54:20 +0100 Steven Chamberlain wrote:
>> If I change all files except CustomCMakeInput.txt to have identical
>> timestamps, then I can reproduce the bug as seen on the buildds:
[snip]
>> And finally, it seems I can avoid that happening by making just the
>> Makefile have a newer timestamp than the others.  The bug is no longer
>> reproducible then:
[snip]
> You may have to consider make's behavior w.r.t. files of the identical
> time stamp:
[snip]
> A target is considered up-to-date if it's timestamp is newer *or same*
> as its prerequisites. Even if a prerequisite was just created.
> (#820658, this is documented make behavior)
> 
> And if I understand this correctly, cmake is doing the opposite:

That is *only* in the if(IS_NEWER_THAN) check which does not come into
play in the RunCMake.Configure test AFAIK.  The way CMake decides whether
it needs to re-configure is the following:

* The "make" tool sees the cmake_check_build_system target in the Makefile
  as always out of date and always runs CMake to do the check.  See
  the `cmake::CheckBuildSystem` method for the implementation.

* CMake reads CMakeFiles/Makefile.cmake and collects the timestamps
  of all the files listed as CMAKE_MAKEFILE_{DEPENDS,OUTPUTS}.

* CMake finds the newest entry in DEPENDS and the oldest entry in OUTPUTS.

* If the newest dependency is newer than (but not equal to) the oldest
  output then it decides to re-run.  This is the same as the "make"
  behavior for identical timestamps.

If you place `VERBOSE=1` in your environment then CMake will print out
what pair of files caused it to decide to re-run.

Steven, in your earlier test that I quoted above, did you ensure that
the timestamps of all files listed as described above (which includes
some under CMakeFiles/) had the same timestamp?  If not then I don't
think the test was set up the way you intended.

-------------------------------------------------------------------------

FWIW I would not consider this test failure to be a blocking issue for
packaging a new CMake on this platform.  The behavior of this logic is
the same as it has been for years in CMake.  It is just that this test
case did not exist before.

-Brad