Live data from Hacker News

A better build system for OCaml

blog.janestreet.com

41–50 of 219 posts

Re: A better build system for OCaml

#41
post #31
post #13

The only thing worse than a complex codebase is a complex build system. I think CMake is an abomination. “Hey go learn this new language to compile this other language!”

I don't mind CMake. It's awful, but I'm already using C or C++, so the bar is set pretty low. It does do a few things right, and at least some of the things it does wrong are manageable. I'll eat at least a bit of shit if it means I can get more than one platform's-worth of build process out of a single set of human-editable configuration files.

Have you tried meson? I used it once many years ago, and it seemed slightly better.

Re: A better build system for OCaml

#42
post #6

I spent several years in Haskell land a while back, my first functional experience after Lisp. Ocaml never clicked for me, I have a rare form of semicolon allergy and Haskell just looked a lot nicer to me. But then I recently tried Reason and enjoyed it A LOT, so everything Ocaml is suddenly interesting.

“If your intention is to compile or interpret files as scripts, double semicolons can and should be avoided when writing in OCaml. Leaving them does not raise errors, but they are useless. The compiler tolerates them to allow copy-paste from UTop to a file without having to remove them.“ https://ocaml.org/docs/toplevel-introduction#loading-librari...

https://reasonml.github.io/ looks cool, OCaml with javascript.

Re: A better build system for OCaml

#43
post #10

I respectfully have to disagree. As Fedora packager for OCaml packages, dune's configuration is yet another one-off, with a weird Lisp syntax, hard to understand, difficult to patch. I'd far rather people stuck to using more familiar Linux build systems. As an upstream OCaml developer, the whole thing falls down the minute you need to integrate other programming languages into your build (or OCaml code into a code ba…

As a user of Linux, I wish Linux distributions would abandon their build systems which really only work well for C and maybe C++, and also only work on one platform (not even the whole of linux!) meaning that packaging has to be duplicated for every OS, and stuck to using more familiar language-specific build systems that work everywhere. (this rant more or less equally applies to all os-or-distro-specific build syst…

If you only care about Linux and MacOS then Nix can be that universal cross language build tool.

Re: A better build system for OCaml

#44
post #10

I respectfully have to disagree. As Fedora packager for OCaml packages, dune's configuration is yet another one-off, with a weird Lisp syntax, hard to understand, difficult to patch. I'd far rather people stuck to using more familiar Linux build systems. As an upstream OCaml developer, the whole thing falls down the minute you need to integrate other programming languages into your build (or OCaml code into a code ba…

I haven't been doing much OCaml in recent years, but I do sometimes check in to see what's going on in OCaml-land, and it seems like dune is what everyone is using now - what are the alternatives?

Using, probably, to be deprecated ocamlbuild, with _tags file which is another made up syntax.

But I'm a new OCaml user, and actively starter using ocamlbuild because dune added layers of indirection really tripped me up at first.

Re: A better build system for OCaml

#45
post #12

I wonder if anyone has used Jane Street's open source OCaml libraries and tools for somewhat serious projects. I took a brief look at these things, and my impression is that their stuff isn't "ready" for anyone outside Jane Street, even though they put a lot of effort in building the ecosystem and open source their code.

I do! Their standard lib replacement was used on the project where I originally learned ocaml, so I have just always used it. You have to be fairly sophisticated at reading fn signatures to find things sometimes but otherwise no complaints with it. It has some very nice features too for example convert functions to/from sexps for all base types can save you a ton of time if you know it's there and plan for it.

I've used some of their other libraries too, their logging and unit test ppx are common maybe even de facto standards as much as the ocaml world has such a thing. I've also used, off the top of my head, their code formatter, one of their test frameworks, their implementations of some advanced data structures.

Sometimes you do run into one like the other commenter said, where that shit just does not work. It depends on an undocumented something they shipped separately, or needs a secret bit of config or whatever. These aren't malicious, I open a ticket and come back in a year or two often they'll be working.

It's not zero frustration but I appreciate their approach of just throwing everything over rather than spending more resources testing and polishing fewer releases. Their code quality is generally very high and even if I can't get something working directly, it provides a rigorous & vetted example implementation.

Re: A better build system for OCaml

#46

Earlier quoted context omitted.

> HM-typed functional programming Mercury also uses Haskell for their backend https://mercury.com/

Too bad they didn't use their namesake: https://mercurylang.org/ Would honestly be a lot more interesting than Haskell.

Thank you for mentioning this, because—not having followed the link—I thought someone was using Mercury for a backend. And... I wasn't sure I was prepared to follow that link.

Re: A better build system for OCaml

#47
post #7

They did an episode of Signals and Threads (Jane Street's technical podcast) about their build systems back in 2020¥. Highly recommended, as are the other episodes, especially The Future of Programming with Richard Eisenberg° and What is an Operating System? with Anil Madhavapeddy§. ¥ https://signalsandthreads.com/build-systems/ ° https://signalsandthreads.com/future-of-programming/ § https://signalsandthreads.com/wh…

Very interesting footnote system. Is it just for fun and aesthetic or have a deeper origin or purpose?

Re: A better build system for OCaml

#48
post #13

The only thing worse than a complex codebase is a complex build system. I think CMake is an abomination. “Hey go learn this new language to compile this other language!”

The ideas embodied in modern target-oriented CMake are worthwhile. It's all hobbled by a dreadful script language but that could be improved with sufficient motivation.

It's hobbled not just by that but by the fact that it's not the thing doing the building. It's a build system for build systems, and suffers from brittleness and confusion as a result.

Re: A better build system for OCaml

#49
post #6

I spent several years in Haskell land a while back, my first functional experience after Lisp. Ocaml never clicked for me, I have a rare form of semicolon allergy and Haskell just looked a lot nicer to me. But then I recently tried Reason and enjoyed it A LOT, so everything Ocaml is suddenly interesting.

It's funny because the thing that always turned me off from Haskell was that it feels like a stream of whitespace and identifies without good visual cues as to structure.

I'm sure once you get the zen of it, it's fine. Like Lisp, I guess, you learn to think in its structure. But looking at a screenful of Haskell to me is intimidating.

Of the bunch I found SML/NJ to be the most readable.

Re: A better build system for OCaml

#50
post #30

Earlier quoted context omitted.

The only thing worse than a complex build system is a simple build system that can't build what you need to build. :(

This means the architecture is also bad, and that is what needs to be fixed.

so simple huh? since you fancy yourself an architect can you let me know how we might fix the architecture of https://github.com/llvm/llvm-project such that CMake is no longer needed?
Post reply on HN