Interesting! Comparisons with alternatives?

[jason-sachs]

Really interesting... I'd like to see whether hancho meets my use case and how it compares to other Python-ish build systems (scons, waf, bazel)

Has anyone already done such a comparison?

[jason-sachs]

I can post some criteria I use, but may need some help evaluating how hancho stacks up against those criteria.

[aappleby]

Yes please, I'm interested in seeing your criteria.

[jason-sachs]

see comment below with my bullet list summary

[aappleby]

I haven't used SCons or waf, but in comparison to Bazel (which I used under the name Blaze at Google):

Bazel is an enormous build system. It can give you hermetic, distributed, multiplatform builds - but it is a very heavy solution.

Hancho isn't really comparable except in syntax spirit. Hancho knows absolutely nothing about toolchains, it's just a task runner at heart. That said, it does enough to be useful and is flexible enough to cover a lot of use cases. And if it breaks, there's only the one file of code to step through to debug it (which you can do easily in VSCode).

[aappleby]

Oh, BTW - Hancho is getting a bit of a redesign based on some feedback, along with a more fleshed out tutorial. The tutorial WIP is in the v010 branch here - https://github.com/aappleby/hancho/tree/v010/docs/tutorial

[aappleby]

Waf and Scons both contain their own Turing-complete programming languages?

Huh. That seems a little ridiculous.

[jason-sachs]

Waf and Scons both contain their own Turing-complete programming languages?

No, but they are written in Python, and let you define tasks in Python, giving you Turing-completeness. I haven't used scons since around 2012, but have been using waf for the past 10 years and want to find a better alternative.

[aappleby]

Ah, I must've misunderstood a comment I found then.

[aappleby]

Oh, the Wikipedia page for Waf says "Offers a Turing-complete..." - which I interpreted to mean they contain another language aside from Python.

[jason-sachs]

I'll summarize waf briefly: (https://gitlab.com/ita1024/waf)

• ridiculously small: the version I use weighs in at 98362 bytes compressed, so we just include it in our source tree, no need to install anything other than Python and the required libraries
• is written in pure Python and will work in Windows/OSX/Linux
• is fast (not sure how to quantify this, but the only perceptible delay is our stupid corporate virus-scanning program which seems to add 10 seconds on first run after a reboot and maybe 0.5-1.5 seconds at startup when we run a build)
• supports Python 2 and 3 (this used to be a concern for us; unfortunately we chose conservatively and are stuck on Python 2.7 which is one reason why I'm trying to find alternatives)
• has one maintainer (Thomas Nagy) who's done an amazing job, including documentation --- but is rather opinionated and some of his choices have been detrimental to my team's use of waf
• multithreaded for speed, but maintains proper ordering based on task dependencies
• contains tooling for C/C++ (as well as some other languages)
  • includes fast dependency scanning of header files (doesn't use gcc -MMD)
  • support for typical compilation/linking tasks, with appropriate compiler flags
• includes logic for locating tool executables (C compiler, java compiler, etc.) within a search path
• uses an object-oriented approach with TaskGen (task generator) and Task objects, and Node objects representing a lightweight abstraction layer over files, and Environment objects representing things like compiler flags
• allows many ways of defining tasks
  • from a command string, with template substitution
  • from a Python function
  • from a Python class
• ❌ relies on a lot of implicit "magic" actions that are hard to understand and override
• ✔️ uses file hashes for determining whether a task has to be executed
• ✔️ separates source and build directories
• can produce a log file (I prefer to keep stdout/stderr relatively brief but be more verbose than the logfile)
• allows for Environments that can inherit settings and override them in child environments
• separates the task definition and dependency phase from the task execution phase
• allows for dynamic dependency generation... but it's not so easy to do so
• documentation doesn't have enough real-world examples for my taste

My team's efforts are in embedded C with code generation, and I prefer not to rely on built-in tooling behavior (why should something look for Visual C++, for example?) ... except for the header file scanning in C, which I don't know how to replicate the niceness of waf, and I'd rather avoid the gcc -MMD approach unless I need it.

[aappleby]

GZipped hancho.py (with comments etc) is currently 10k for comparison, that'll probably go down a bit once I finish the v0.1.0 version and clean things up.

[aappleby]

Hancho is

• 10k gzipped
• Just one python file
• Fastish? I haven't tested it on anything large but it doesn't do anything heavyweight.
• Supports only Python 3.10+, though most of that is for Python convenience like match statements. Moving it back a few versions should be doable.
• Not multithreaded, but runs commands via asyncio so jobs will run in parallel up to os.cpu_count() (or whatever you set it to)
• Contains zero tooling for anything except for a few lines to parse GCC .d files
• Doesn't do any dependency scanning aside from the .d files
• Doesn't know how to locate tools
• Tasks are just dicts with a few special fields to tell Hancho what the "upstream" and "downstream" links in the dependency graph are
• Uses only mtime, no file hashing
• Zero magic actions
• Defaults to separate source and build directories, but the build directory is just another template and you can set it to whatever you want
• Defaults to a single status line during build, but has 'verbose' and 'debug' flags for more output
• v010 will have 'build_config' objects that can do the 'environment' thing I think, not quite finished yet.
• Most task definition and dependency checking happens before task execution, but additional tasks can be created during execution.
• 'Dynamic' dependency generation should work but I need some real-world examples to verify
• Too new to have any real-world examples aside from my own personal projects.

[jason-sachs]

Uses only mtime, no file hashing

Ah -- ok, that's probably a nonstarter for our use case. I like the general philosophy you've chosen, though! Good luck; if you ever do facilitate hash-based builds, let me know. (is it worth it to file an issue as a future feature request? or is the choice of mtime pretty much baked into the design?)

[aappleby]

It's not baked into the design, but if you use hashing then you have to store the hashes somewhere and for now I'd prefer if Hancho doesn't create any extra files that have to be .gitignored.

Might revisit post-1.0