Interesting. Still not sure I agree, but I’m open to persuasion on that last point.
You asked for feedback about what annoys me about Dune, and I can infer from that you might also be interested in what I like about OMake compared to it, so let me offer a story that might provide some background color.
Many centuries ago, when the Earth was young and BSD make(1) was the only build tool any of us had, it fell to me to bring some order and discipline to build logic for a very large software system that had grown into a system of several dozen Makefile instances using a library that comprised, oh I’m guessing, around 10k lines of make(1) logic.
I reached for the only tool at the time I knew had been successfully (for some value of “success”) used for such a thing: the imake tool from X Window System. Ye gods, what a mistake that turned out to be. I would show you my scars, but they are in some intimate locations. I learned to hate the Makefile language— all variations on it, from BSD to GNU to whatever else— with the blazing fire of a thousand angry suns.
I tried a variety of other options, e.g. Jam and GNU Automake. I hated them all. Eventually, I got really crazy and wrote a system in Perl 5 that I called Conjury. The idea was fairly simple: you write your build logic in an all singing all dancing fully capable industrial grade programming language using a library that results in generating your Makefile instances for you. Developers still get to use their make command line tool, but they write their build logic in Perl. (Insert image of Galadriel explaining to the hobbits why they probably don’t want to give the One Ring to her.)
From that, I learned the same thing that the ninja people eventually learned: the make tool and its language is just insufficient. You really need the tool itself to have a comprehensive view of the whole project, not just a capsule view of each subproject.
So, I rewrote Conjury to eliminate the make tool entirely and replace it with a similar tool (called “cast”) that was written in Perl itself. This turned out to be not a half bad approach to the problem, and I was allowed to post it to CPAN, but day jobs change, and I took another one where they didn’t need me to maintain the build logic. The Perl version of Conjury became something I hacked on in my hobby time, and the CPAN version fell into disrepair.
One thing that I learned to appreciate well, from basically reimplementing all of make(1) (and then some) in Perl, is that the language that appears in Makefile programs is deceptively tenacious. People keep using it. It’s a very useful language. Things I thought were warts were actually beauty marks. Because it’s a special purpose language and not a general systems programming language, it’s possible to write logic that expresses build rules and actions concisely and fairly clearly. That’s harder in Perl, and I don’t think I got it right. (I was probably bumping up against the same problems with Perl that made a whole raft of people decamp and make Raku happen. Have I mentioned lately that Raku is an awesome language. I should write more Raku.)
I discovered OCaml in 2002, around the same time I was tiring of Perl. Not long after, I discovered OMake. When I first read the [short, and excellent] reference manual for the OMake language, I was beside myself. Here was a make variant that seemed to correct all of the things about make that made me hate it, while leaving in place all the special purpose features that I had learned to appreciate were what made make into a tenacious weed that seemed like it might never be displaced by anything better.
I didn’t think the original OMake standard library was very rich or extensible, and I thought I could do better. So I reimplemented most of the ideas in the Perl implementation of Conjury into an OMake library of the same name. (Then I rewrote it, after I had learned more OMake, and I discovered just how rich a language it is. I mean, ye gods, somebody wrote an entire C language parser in under 4k lines of OMake— it was last updated 12 years ago, because it still works. Because of course you would do that. Why wouldn’t you do that?)
So, I’ll agree that OMake is not the tool the community should be using right now. It’s not well maintained, the standard library is not very rich, and my Conjury library needs far more time and energy put into it than I can afford to give personally. But the least pressing problem with OMake is the quality of the language. I think the language is awesome, and I’m sad that its library leaves so much to be desired compared to the features now offered by dune.
So I hear your distaste for the OMake language, and I have to wonder if it comes from the same distaste for make variants that I developed all those years ago, and it took me so long to overcome before deciding I was wrong about it?
As for what I like now? Well, I’ve grudgingly come to respect bazel after using it my day job for the last four years. I wish Starlark weren’t a Python variant, but I respect the choice because Python is so widely known.
My advice to the dune team is to study bazel intensely. In fact, if I were being puckish, I’d advise the dune team simply to put all their code into maintenance mode and go find a way to make bazel rules that can serve as a replacement for it. Which is basically OBazl— you guys should drop everything and go make OBazl happen.
I’m not gonna be at all surprised if the dune team decides they can do better than bazel. Maybe by doing to OCaml what Starlark did to Python while stealing all its other awesome ideas like aspects and toolchains and distributed builds, et cetera. I wish them luck.
But really, I think OBazl is what we need.