[GSoC 2022] Ham: Status Update | Haiku Project

Hello everyone. This is a brief update on the Ham project - a drop in replacement for the Jam build system. For those more curious about the technical details, there will be a larger blog post on Ham’s action modifier implementation coming soon.

This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/dominicm/2022-07-21_gsoc_2022_ham_status_update/

Stupid question: what is wrong with current Jam and why Ham would be better?

Perhaps previous post would answer…

Current Jam has a lot of bugs/limitations, both small (taking a sublist with an endpoint just doesn’t return anything) and fundamental (Jam doesn’t track it’s environment or Jamfiles so it can’t always tell when something needs to be rebuilt). It’s also generally a difficult codebase to work in.

Ham aims to be:

  1. Faster
  2. Usable as a library for IDEs
  3. More extensible
  4. Thoroughly tested
  5. Have better caching capabilities

It also has compatibility features that subsume other Jam forks, so it’s an all-in-one tool.


I’d be happy to answer any questions anyone has! I know that a build system rewrite isn’t exactly the most tangible project, but this should hopefully make future extensions a lot easier.

1 Like

Great! If Ham can do what Jam does but more efficiently and organized, that might just save us from having to rewrite jamfile definitions later.

After all, Fuchsia used to use (or maybe still uses) a preprocessor for Ninja Build called Build Ninja to combine build steps for parallel builds on Google’s datacenters. If Ham can become an integrated one step process for a build chain, that’ll be fine with me.

1 Like

That’s so cool, nice project!