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

[Andreas Beckmann]

On Thu, 7 Apr 2016 14:54:20 +0100 Steven Chamberlain
<steven at pyro.eu.org> wrote:
> If I change all files except CustomCMakeInput.txt to have identical
> timestamps, then I can reproduce the bug as seen on the buildds:
> 
> -rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:46:31.600236000 +0000 cmake_install.cmake
> -rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:46:31.600236000 +0000 Makefile
> -rw-r--r-- 1 pbuilder1 build    1 2016-04-07 13:46:31.600236000 +0000 CustomCMakeStamp.txt
> -rw-r--r-- 1 pbuilder1 build    1 2016-04-07 13:46:31.600236000 +0000 CustomCMakeOutput.txt
> -rw-r--r-- 1 pbuilder1 build    1 2016-04-07 13:46:31.600236000 +0000 CustomCMakeDepend.txt
> drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:31.600236000 +0000 CMakeFiles
> -rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:46:31.600236000 +0000 CMakeCache.txt
> drwxr-xr-x 6 pbuilder1 build    6 2016-04-07 13:46:31.600236252 +0000 ..
> drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:32.653236466 +0000 .
> -rw-r--r-- 1 pbuilder1 build    1 2016-04-07 13:46:32.673236479 +0000 CustomCMakeInput.txt
> 
> leads to:
>   Expected stamp '1' but got: '2'
> 
> 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:

You may have to consider make's behavior w.r.t. files of the identical
time stamp:

=======================
all: race

foo:
        echo foo > $@

foobar: foo
        cat $< > $@

test: foobar
        grep foo $<

clean:
        $(RM) foo foobar

norace: clean
        $(MAKE) test

race: clean
        echo barf > foobar
        $(MAKE) test

race2: clean
        echo barf > foobar
        sleep 0.5
        $(MAKE) test

race3: clean
        echo barf > foobar
        sleep 0.99
        $(MAKE) test
=======================

This frequently fails even on high-resolution file systems.

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:

On Thu, 7 Apr 2016 08:43:08 -0400 Brad King <brad.king at kitware.com> wrote:
> FYI, the IS_NEWER_THAN check actually documents that it returns true
> when the times are exactly equal:
>
>   https://cmake.org/cmake/help/v3.5/command/if.html
>   "If the file time stamps are exactly the same, an IS_NEWER_THAN
>   comparison returns true, so that any dependent build operations
>   will occur in the event of a tie."

So good luck if both cmake and make get involved in such a race.


Andreas