have you been building stuff in public but without talking about it?
i want to know
Conversation
Replying to
> redo: implementation of Redo build system in Erlang
what's been your experience with this? have you tried tup? and would be interesting in chatting about zap?
what I don't like about redo is that it feels so bashy/scripty -- I want build tools to also *feel* robust
1
Replying to
I liked the redo idea. The shell + filesystem was a serious limitation for me, so I implemented it in Erlang and generalized it to all kinds of "state with a name". That version I really like, and it is quickly turning into the backbone of exo. I've not looked into tup or zap.
1
Just checked tup site, so I'm very uninformed. Assuming the core idea is the inverted dep graphs. I can see that work for large systems. I tried that in my redo implementation but realized it conflicts with the implicit dependency discovery in redo, so my "push" is just a "pull".
1
1
For zap it's hard to see from a quick look at the web page what makes it distinct from other approaches. One thing though: I'm really starting to like just having build rules be plain code, in my case Erlang, being able to generate dependencies on the fly. Can zap do that?
1
But I have to mention that my use case is a bit perverted. I'm managing everything in this system: build, deployment, partial restart, database updates, subsystem connections, embedded device flash & power cycle etc. It supports a lot of experimental things so plain code is good.
Looking at tup. Might be missing something, I was wondering how can doing an operation on an in-memory dependency tree ever be slower than checking a lot of time stamps. So the way to make that fast would be to use file system notifications to avoid polling, and an inverted tree.
1
Show replies
Replying to
i wouldn't go as far, but really what you want is an incremental computation graph with side effects
e.g, bazel meets terraform sort of thing
1