Call for 1.10 testing: Dynamic Dependencies, cleandead, restat, rules, ...

[Jan Niklas Hasse]

Hi everyone,

we'd like to release 1.10 from current master.

The big new feature will be the new dyndep binding to support Fortran and C++20 modules: https://github.com/ninja-build/ninja/pull/1521

Also there are three new tools:

cleandead: https://github.com/ninja-build/ninja/pull/1432

restat: https://github.com/ninja-build/ninja/pull/1685

rules: https://github.com/ninja-build/ninja/pull/1025 (this one actually existed in older versions of Ninja and is now back)

Ninja itself can now also be built with CMake. For the release this will be done automatically by GitHub Actions, uploading the binary archives automatically and thus making the whole process a lot easier. If you want to test those binaries, check out: https://github.com/ninja-build/ninja/runs/396697164

For a complete list of changes see: https://github.com/ninja-build/ninja/compare/v1.9.0...adcf925c45afb19eacaa9a78a6d2ff519ec466c0

Please test a build of the master branch with your projects and report any problems. Thanks!

[Brad King]

On 1/18/20 7:24 AM, Jan Niklas Hasse wrote:
> The big new feature will be the new dyndep binding to support Fortran and C++20 modules: https://github.com/ninja-build/ninja/pull/1521

Yay!

> Please test a build of the master branch with your projects and report any problems.

I've been running a version based on `master` with the dyndep feature for
a long time on Linux, macOS, and Windows on several machines. I have not
noticed any problems.

Also, part of CMake's own nightly testing infrastructure includes builds
that drive testing of CMake's Ninja generator using a `ninja` that
is built from its upstream `master` every day. They are all clean.

Thanks,
-Brad

[Ben Boeckel]

On Mon, Jan 20, 2020 at 11:47:19 -0500, 'Brad King' via ninja-build wrote:
> Also, part of CMake's own nightly testing infrastructure includes builds
> that drive testing of CMake's Ninja generator using a `ninja` that
> is built from its upstream `master` every day. They are all clean.

Note that `master` is reporting as `1.9.0.git` right now, so our 1.10
version checks are failing right now, so we might not actually be
testing the new codepaths in CMake itself. Maybe a local patch to
`version.cc` should be done on some machines to test them?

--Ben

[Brad King]

I meant that paragraph only for stating that we haven't detected
any regressions of 1.9's functionality in CMake's nightly testing.
My first paragraph refers to local builds that enable the dyndep
feature that I've been using.

-Brad

[Ben Boeckel]

On Mon, Jan 20, 2020 at 16:19:45 -0500, Brad King wrote:
> I meant that paragraph only for stating that we haven't detected
> any regressions of 1.9's functionality in CMake's nightly testing.
> My first paragraph refers to local builds that enable the dyndep
> feature that I've been using.

Ah, indeed. That said…should we masquerade as 1.10 for testing purposes
for both ninja's and CMake 3.17's sakes?

--Ben

[Brad King]

On 1/20/20 4:41 PM, Ben Boeckel wrote:
> Ah, indeed. That said…should we masquerade as 1.10 for testing purposes
> for both ninja's and CMake 3.17's sakes?

I've done that locally. `ninja rebuild_cache; ninja` without a double
run of CMake works. The Fortran tests all pass, including those with
Fortran module dependencies.

-Brad

[Brad King]

Jan,

On 1/20/20 5:04 PM, Brad King wrote:
>> should we masquerade as 1.10 for testing purposes

> I've done that locally.

That testing led to discovering a need for this fixup:

https://github.com/ninja-build/ninja/pull/1721

-Brad

[Jan Niklas Hasse]

Is there a bug that needs the PR or is it just to improve performance?

[Brad King]

On 1/23/20 3:22 AM, Jan Niklas Hasse wrote:
> Is there a bug that needs the PR or is it just to improve performance?
>

> https://github.com/ninja-build/ninja/pull/1721

Performance and convenience. The goal is to avoid requiring the build graph
to be loaded just to operate on the log file. However, I see from discussion
in PR 1721 that there may be path normalization requirements for the build
graph, and at least a deeper investigation may be needed.

I should have given more detail in my previous post but I mixed up the
long-existing recompact tool with the new cleandead tool and thought this
was just a quick fixup for a new tool. However it is actually a change to
an already-released tool and so needs more care.

The problem came up in CMake here:

https://gitlab.kitware.com/cmake/cmake/issues/20247

CMake can work without the change if needed. I don't think this needs to
block the 1.10 release for Ninja.

Thanks,
-Brad

[Christoph]

Hello Jan,

I gave the current Master (1.10.0git)  a try, together with the current master of CMake (will be 3.17). After fixing a bug in our code to detect Fortran language support, it works flawlessly. Our whole mid-size code for numerical software just compiles, now with the Fortran parts!

Actually, I wanted to remove all Fortran libraries and replace them with C binding, but the upcoming Ninja support it is one argument less to do so :-)

Have a good release

Christoph