3 ms·

Do you mean jobserver client or sever? As for "ninja with jobserver client" there's already https://github.com/Kitware/ninja https://github.com/Kitware/ninja

• stormbrew 5y ago
  > Do you mean jobserver client or sever? Both. But server is more important to me usually (ninja running cargo, in particular -- but also sometimes ninja running make or ninja running ninja). Technically you can obviously kinda trick client-only support into being server support by wrapping ninja in a jobserver like make, and letting that jobserver cascade down, but that's pretty gross. So while client support is nice, it's not really sufficient. I actually don't think I have much use for client-without-server at all, the main configuration I need client for at all is ninja->ninja. There's also that kitware's is a one-purpose fork that's just kind of a pain to install in CI because lack of packages, but it's pretty easy to `cargo install n2` on a machine where I'm building rust anyways, and cache the CARGO_HOME so it doesn't build every time. To be honest, with the fact that compilers are no longer single-threaded almost as a rule, something like jobserver seems like an essential feature in a build system now. It's basically impossible to meaningfully limit concurrency without some level of coordination or fuzzy imperfect indicators like load average. I hope other compilers follow rust's lead here and implement client support eventually. (and then hopefully a more robust common protocol can evolve out of it)