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

Jan Niklas Hasse

unread,

Jan 18, 2020, 7:24:52 AM1/18/20

to ninja-build

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

unread,

Jan 20, 2020, 11:47:22 AM1/20/20

to Jan Niklas Hasse, ninja-build

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

unread,

Jan 20, 2020, 4:07:50 PM1/20/20

to Brad King, Jan Niklas Hasse, ninja-build

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

unread,

Jan 20, 2020, 4:19:48 PM1/20/20

to ben.b...@kitware.com, Jan Niklas Hasse, ninja-build

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

unread,

Jan 20, 2020, 4:41:09 PM1/20/20

to Brad King, Jan Niklas Hasse, ninja-build

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

unread,

Jan 20, 2020, 5:04:18 PM1/20/20

to ben.b...@kitware.com, Jan Niklas Hasse, ninja-build

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

unread,

Jan 22, 2020, 11:24:21 AM1/22/20

to Jan Niklas Hasse, ben.b...@kitware.com, ninja-build

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

unread,

Jan 23, 2020, 3:22:01 AM1/23/20

to ninja-build

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

Brad King

unread,

Jan 23, 2020, 9:00:04 AM1/23/20

to Jan Niklas Hasse, ninja-build

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

unread,

Feb 4, 2020, 11:34:56 AM2/4/20

to ninja-build

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 :-)