llvm dev - May 2019 - Prevent ninja from rerunning cmake in a new build directory

Just posted this fix on ninja's github page, but figured I'd share it
with
a larger audience.

Every time I run cmake && ninja in a new build directory, ninja will
rerun
cmake because the entry for build.ninja in .ninja_log is older than the
timestamp on CMakeCache.txt, even if the timestamps on the actual file
isn't older.

The following patch fixes the problem, i.e., there's no need to add
build.ninja to the ninja_log:

diff --git a/src/ninja.cc b/src/ninja.cc
index a093cd1..810b22d 100644
--- a/src/ninja.cc
+++ b/src/ninja.cc
@@ -249,8 +249,6 @@ bool NinjaMain::RebuildManifest(const char*
input_file, string* err) {
     return false;

   Builder builder(&state_, config_, &build_log_, &deps_log_,
&disk_interface_);
-  if (!builder.AddTarget(node, err))
-    return false;

   if (builder.AlreadyUpToDate())
     return false;  // Not an error, but we didn't rebuild.


hth...
don
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190524/61b2ec68/attachment.html>

Please find a better fix here:
https://github.com/ninja-build/ninja/pull/1580/commits/9221541695206b7e7e89f9b8743d8eae56634999


On Fri, May 24, 2019 at 11:36 AM Don Hinton <hintonda at gmail.com> wrote:
> Just posted this fix on ninja's github page, but figured I'd share
it with
> a larger audience.
>
> Every time I run cmake && ninja in a new build directory, ninja
will rerun
> cmake because the entry for build.ninja in .ninja_log is older than the
> timestamp on CMakeCache.txt, even if the timestamps on the actual file
> isn't older.
>
> The following patch fixes the problem, i.e., there's no need to add
> build.ninja to the ninja_log:
>
> diff --git a/src/ninja.cc b/src/ninja.cc
> index a093cd1..810b22d 100644
> --- a/src/ninja.cc
> +++ b/src/ninja.cc
> @@ -249,8 +249,6 @@ bool NinjaMain::RebuildManifest(const char* input_file,
string* err) {
>      return false;
>
>    Builder builder(&state_, config_, &build_log_, &deps_log_,
&disk_interface_);
> -  if (!builder.AddTarget(node, err))
> -    return false;
>
>    if (builder.AlreadyUpToDate())
>      return false;  // Not an error, but we didn't rebuild.
>
>
> hth...
> don
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190524/e6019501/attachment.html>

The ninja developers want to fix this in a more elegant way, which
unfortunately will also require a change to cmake.  So, if you'd rather not
wait, or like me, can't upgrade cmake, you can use my fork here:
https://github.com/donhinton/ninja

hth...
don

On Fri, May 24, 2019 at 2:49 PM Don Hinton <hintonda at gmail.com> wrote:
> Please find a better fix here:
>
https://github.com/ninja-build/ninja/pull/1580/commits/9221541695206b7e7e89f9b8743d8eae56634999
>
>
> On Fri, May 24, 2019 at 11:36 AM Don Hinton <hintonda at gmail.com>
wrote:
>
>> Just posted this fix on ninja's github page, but figured I'd
share it
>> with a larger audience.
>>
>> Every time I run cmake && ninja in a new build directory, ninja
will
>> rerun cmake because the entry for build.ninja in .ninja_log is older
than
>> the timestamp on CMakeCache.txt, even if the timestamps on the actual
file
>> isn't older.
>>
>> The following patch fixes the problem, i.e., there's no need to add
>> build.ninja to the ninja_log:
>>
>> diff --git a/src/ninja.cc b/src/ninja.cc
>> index a093cd1..810b22d 100644
>> --- a/src/ninja.cc
>> +++ b/src/ninja.cc
>> @@ -249,8 +249,6 @@ bool NinjaMain::RebuildManifest(const char*
input_file, string* err) {
>>      return false;
>>
>>    Builder builder(&state_, config_, &build_log_,
&deps_log_, &disk_interface_);
>> -  if (!builder.AddTarget(node, err))
>> -    return false;
>>
>>    if (builder.AlreadyUpToDate())
>>      return false;  // Not an error, but we didn't rebuild.
>>
>>
>> hth...
>> don
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190525/5ece9b10/attachment.html>