Build on windows does not discover changed source files

[Tino]

It seems the current cmake configuration does not always grab the correct revision number and source files.
Steps to reproduce:
- bzr pull (source code rev7010 -> 7013)
- ninja (does run cmake, compiles and links)

Now in build_info.cc contains the correct entries:

  static const std::string wl_bid = "bzr7013[trunk]";
  static const std::string wl_bt = "Release";

The timestamp of this file is 8:16, widelands.exe has the timestamp 8:24.
If i run widelands it displays "Widelands bzr 7010[trunk](Release)"

Another ninja call grabs now many new files to compile.
After this, widelands.exe has the current revision.

[SirVer (sirver)]

I see that too. Two ideas: one, the configure_file() call does not seem to check if its output is there or its input has changed, so that could be it. two, detecting the bzr revision has no 'input files' defined, so make does not know when to rerun it.

[Jens Beyer (qcumber-some)]

add_custom_target (BzrRevision) is always considered OUT OF DATE and therefor ran everytime the build is ran.

If I remember correctly, this has also been the way before the cmake redesign (I could be wrong, though).

--

configure_file() should (according to docs) check if the input has changed (and runs cmake again in that case), The output can only change if the cmake is ran again (at least by configure_file - if there are other qays to modify config.h, this is probably the cause of this error)

--

What I would like to know, does this really only happen on Windows?

[SirVer (sirver)]

On 26.06.2014, at 21:14, Jens Beyer <email address hidden> wrote:

> add_custom_target (BzrRevision) is always considered OUT OF DATE and
> therefor ran everytime the build is ran.
>
> If I remember correctly, this has also been the way before the cmake
> redesign (I could be wrong, though).

configure_file() however is not. I’ll put my money on this being the problem.

>
> --
>
> configure_file() should (according to docs) check if the input has
> changed (and runs cmake again in that case), The output can only change
> if the cmake is ran again (at least by configure_file - if there are
> other qays to modify config.h, this is probably the cause of this error)
>
> --
>
> What I would like to know, does this really only happen on Windows?
>
> --
> You received this bug notification because you are subscribed to
> widelands.
> https://bugs.launchpad.net/bugs/1334117
>
> Title:
> Build on windows does not discover changed source files
>
> Status in Widelands:
> Confirmed
>
> Bug description:
> It seems the current cmake configuration does not always grab the correct revision number and source files.
> Steps to reproduce:
> - bzr pull (source code rev7010 -> 7013)
> - ninja (does run cmake, compiles and links)
>
> Now in build_info.cc contains the correct entries:
>
> static const std::string wl_bid = "bzr7013[trunk]";
> static const std::string wl_bt = "Release";
>
> The timestamp of this file is 8:16, widelands.exe has the timestamp 8:24.
> If i run widelands it displays "Widelands bzr 7010[trunk](Release)"
>
> Another ninja call grabs now many new files to compile.
> After this, widelands.exe has the current revision.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands/+bug/1334117/+subscriptions

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[SirVer (sirver)]

I can no longer reproduce this with a recent cmake version (3.4). Maybe this was a cmake issue that got fixed or our build system is now more reliable than 2 years ago. I cannot say for sure.

If this resurfaces, please reopen.

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.