>> Isn’t that just Make?

> Yep! But what if we add mappings and collections?

These are called pattern rules in make:

https://www.gnu.org/software/make/manual/html_node/Pattern-R...

This is the best resource I've found on make to get a low friction build system up and running. Some parts are a bit dense if you're relatively new to make or used to someone else setting it up for you, but if you have the gnu make manual side-by-side for reference you should be good to go:

https://make.mad-scientist.net/papers/advanced-auto-dependen...

If you've ever been frustrated with how time consuming it is to manually write make rules then the above method will probably be a night-and-day difference from what you're used to.

I'd also strongly suggest either disabling builtin implicit rules with -r or reading up on all of them here:

https://www.gnu.org/software/make/manual/html_node/Catalogue...

Great resources, thank you! I think I came across some of these ideas before and it might have been as simple as me resenting the syntax. I'll touch up on my `make` knowledge and try to make Piper more ergonomic!

Please don't do that! Good reasons to borrow ideas from make would be familiarity for those coming from make, but definitely not because make is ergonomic. The entire reason you must put in tons of mental effort to grok this one true method of make usage I linked above is specifically because of how non-ergonomic make is out of the box.

My comment was meant to be practical advice considering make's popularity. A while back I wanted to replace a legacy script that generated Makefiles for a project at work, and I started out by making something very similar to Piper in python so it was easy for coworkers, etc, but ended up finding the guide I mentioned in my above comment while doing gcc dependency generation. Since I was targeting make underneath anyways, and my needs were less complex than I thought, I ended up scrapping my redundant python build tool.

Oops I worded it badly! I meant take some theory from Make and modify it to be more ergonomic before adding it into Piper. A la rethinking it all with new knowledge I gain.

If you haven't already, I'd seriously suggest having a look at redo (the theory but also apenwarr's implementation at https://github.com/apenwarr/redo).

It's not going in the same direction you are exactly but building a mental model of it in my head was salutary in terms of thinking through the purpose and implementation of build tools and hopefully it'll be similarly useful to you.