[rtpg]

Yeah I'm a bit sad about build systems.

I wanted to write a Postgres extension/fork, and was thinking "oh I'll just replace some bits with Rust".

Unfortunately everything is `make`, which is great when you're setting something up and have a huge process... but it's very hard to make some changes without figuring out the entire flow.

Someone that could somehow wrap make to make it easier to make incremental changes on existing projects could help fuel a lot more experimental changes.

[boris]

>... wrap make to make it easier to make ...

I think there is a deep truth in (unintended?) pun: those who don't understand make are bound to reinvent it, poorly.

[rtpg]

I feel like I "get" make, but when you have autotools in front of it you end up with stuff like [0], and Makefiles kicking off other Makefiles.

It's not the worst thing to ever grace the planet by a long shot, but I think it suffers from the same problem that bash scripts have. Everything is string-ly typed and you can only build up a thing to a certain level of complexity easily.

There's of course a lot of requirements in systems software, of course. And a lot of difficulty stems more from the C ecosystem's difficulties with packaging (where are the C equivalents to "environments" you find in Python/Ruby so you don't have to pass every lib in explicitly?)

I think there's some useful opportunities somewhere here.

[0]: https://github.com/postgres/postgres/blob/master/src/Makefil...

[boris]

> Everything is string-ly typed and you can only build up a thing to a certain level of complexity easily.

Yes, make was designed for the 1970 world, where all you care about is building simple utilities on Unix. There was no today's complexity (out of tree builds, cross-compilation, etc) nor "alien" platforms like Windows where people have spaces in their paths.

What we need is to redesign make to handle today's requierements. And this is what we are trying to do with build2.