Distribute kitware fork with support for Fortran builds and make-style jobserver

[jcfr]

Checklist

• Used a fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[frol]

I suggest you create a feedstock fork as well instead of hijacking the upstream project packaging.

[jcfr]

Thanks for reviewing. 🙏

( Disclaimer: I work at Kitware )

suggest you create a feedstock fork as well instead of hijacking the upstream project packaging.

To clarify, the features available in the Kitware fork have been proposed to the upstream project:

• (1) dyndep: dynamically discovered dependencies for Fortran and C++20 modules ninja-build/ninja#1521 dyndep: dynamically discovered dependencies for Fortran and C++20 modules
• (2) Add GNU make jobserver client support ninja-build/ninja#1140 Add GNU make jobserver client support

The community of ninja users is eager to use them and have these features integrated.

The good news is that the first PR adding support for fortran has been integrated in the upstream ninja on April 20, that said it is not yet available in a tagged ninja release. (see ninja-build/ninja@2e64645)

On the other hand, the support for GNU make jobserver client support hasn't been integrated yet.

Question 1: To avoid building the Kitware fork, would you consider building the latest version of ninja ?
Question 2: And would it be okay to patch the source to add support for job-server ?

That said, I still think building the kitware fork is a good compromise as it is exactly v1.9.0 with only these two features integrated.

Finally, I think creating an other feedstock would confuse the user and create more work for everyone.

Thanks again for re-considering

a selection of comments from the community to support the integration of the job-server feature

• March 10 2017: I would like too have this feature merged, i simply cannot convert all projects to ninja-build because i'm not allowed to do that.

• April 12 2017: Can I just add my voice to the list of people who would like this to be merged? At my company we also use a nested build system, and with this patch it makes ninja behave very nicely indeed. We're not in the position to make ninja build everything yet.

• Nov 11 2017: This would be really useful too when invoking ninja as part of another build tool, such as cargo.

• Nov 12 2017: This should be very useful for super-project build, in our large code base, due to different compiler/environment config, we can not include all projects in one single ninja build, so we have 1 top-level and N sub-projects built by ninja , this config trigger Y*N problem.

• Dec 17 017: +1 - this is highly interesting for parallel builds with catkin_tools ...

• Jan 6 2018: I would like to add my voice to having support for GNu make job-server support in ninja.

• ....

And many more comment like these ones can be found in the associated issue, see ninja-build/ninja#1139

[frol]

I am sorry, but as a user, I would find this decision [publishing a fork instead of an upstream release] surprising. Having a separate package is completely fine and the download stats for the forked package may show the upstream devs the demand for the feature.