Page MenuHomeFreeBSD

Mk/Uses/ninja.mk: add support for devel/samurai
AbandonedPublic

Authored by tobik on Mar 20 2021, 5:55 PM.

Details

Reviewers
None
Group Reviewers
O5: Ports Framework(Owns No Changed Paths)
portmgr
Summary

Current version of Samurai is compatible with Ninja 1.9.0. It has fewer dependencies and is a simpler implementation than Ninja. Alpine Linux uses Samurai instead of Ninja (see [0] for the original proposal about this). CMake and Meson have native support for it nowadays. This does the rest and hooks it up to the framework to make it trivial to experiment with it. OpenBSD Ports has a similar USE_NINJA=samurai knob for this but only for cmake-based ports.

[0] https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 38477
Build 35366: arc lint + arc unit

Event Timeline

tobik published this revision for review.Mar 22 2021, 10:09 AM

I do like it, I would be interested in a exp-run with both to see if there is any difference, I bet ninja vs samurai itself won't bring anything, but the fact we don't need python do build samurai, will make project using ninja (well samurai here ;)) appear earlier in the build process which may have an impact.

  • Include newly added sysutils/fluxengine
  • sysutils/fluxengine generates broken Ninja files; fix that
  • export SAMUFLAGS to make samu builds respect MAKE_JOBS_NUMBER

Apparently ninja defaults to running things in parallel, but samu does not.
Edit: hmm, no I think I'm wrong here, but SAMUFLAGS should be set regardless since some ports (for example, sysutils/fluxengine) just call ninja without any args and do not respect MAKE_JOBS_NUMBER without it.

  • Also pass -v in SAMUFLAGS for ports that call ninja on their own and ignore MAKE_ARGS
In D29353#657807, @bapt wrote:

I do like it, I would be interested in a exp-run with both to see if there is any difference, I bet ninja vs samurai itself won't bring anything, but the fact we don't need python do build samurai, will make project using ninja (well samurai here ;)) appear earlier in the build process which may have an impact.

Asked for an exp-run here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254678

  • Add fix for floating point exception bug with NINJA_STATUS=%p
  • Update review from the right branch...
  • Update devel/samurai to latest master with upstream fix for the fpe bug
  • Fix x11-wm/mutter build order bug with patch from Aports
  • Fix x11/brisk-menu build order bug
  • Add missing USES=python:build to some ports that got it through ninja previously
  • Fix lang/swi-pl build by adding missing USES=readline (previously implicit through ninja->python->readline)
  • Only append -v to MAKE_ARGS when using ninja. samu already gets it via SAMUFLAGS. ninja supports GNU-style arguments (flags in any order) while samu does not and -v gets added last. This should fix the immediate error in www/chromium (build goes further but complete build untested)
  • More missing USES=python:build fixes
  • Add explicit USES=ninja:build to multimedia/handbrake (previously got it through meson but now needs the samu alias)
  • Attempt to fix build order bug in x11-fonts/font-manager
  • Rebase
  • Try to unbreak www/deno (untested)
  • devel/meson, Mk/Uses/meson.mk: Do not force color output

By default Meson forces color output. Ninja strips the escape
sequences before they go into the log. Samurai does not do that,
so we end up with some garbage in the logs. Pass -Db_colorout=never
to Meson to disable colors in general. Also see
https://mesonbuild.com/Builtin-options.html

This requires a small backport in devel/meson since the b_colorout
option is broken with Clang at the moment.