Hacker News Reader

Comment by rwmj | Hacker News Reader

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 base written in another language).

(This rant more or less equally applies to other language-specific build systems.)

View on HN

> more familiar Linux build systems

"Familiar" is not a property of any system. It's a relation between a system and a user.

Some Linux build systems maybe be more familiar to some users, but will be less familiar to others. When picking a build system, you can't just look at the system itself and declare it familiar or not.

It's not even enough to look at the total number of users familiar with some thing. Hindi is one of the most familiar languages in the world, but you're probably gonna have a bad time if you use it for the menu in a cafe in rural Texas.

You have to look at your actual cohort of users (and potential future users) and see what's familiar to them. This is one of the key reasons why usability is actually a deeply hard problem. So much of usability hinges on familiarity, but familiarity is a human-specific highly variable property.

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 systems)

---

This rant is only semi-serious. I do see some value in the Linux distribution style packaging. In particular, I do sympathise with the need to do cross-language builds. But goodness are they a pain to work with, and probably the biggest barrier to me shipping software on Linux.

My hope is that eventually an evolution on build systems like bazel/buck2 will lead to a truly universal build system that is both cross-platform and cross-language. But unfortunately it doesn't look like it's coming soon.

> [Distro-specific build systems are] probably the biggest barrier to me shipping software on Linux.

Don’t[1]. Ship source tarballs (or VCS tags).

I’ll grant that most distros’ build systems are antiquated and, in places, silly. (That includes Nixpkgs, first released 2006.) We could really use some fresh ideas there.

But they’re also not for you (or me) in your (or my) capacity as a software author. They’re there for a person who works on packaging software for, most of the time, a single distro, and their balance of complexity and flexibility is calibrated accordingly. One of the functions of that person is also to keep you honest and represent the interests of users before you, because they have more expertise than the users but not as much of an attachment to your software as you. The ecosystem is less healthy when the author tries to fill in for the packager.

“But then the users will come to my bugtracker to complain about bugs in patched versions!” Pre-Google, we used to have a solution for that: a configure option to set the bug reporting email, present in all GNU software. Nowadays it’s not clear what a good solution could be, but it does seem like, unfortunately, the author will have to maintain a table of packager contact information for the end users.

[1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job....

That doesn't scale though beyond the most popular open source apps especially those in c/c++

Less popular apps or closed source apps don't work. Things with old dependencies won't work. Other language with package manager which depend on dependencies and dependency versions that may not be in distro packages may have trouble.

For the core the distro model might work. For the rest maybe something like flatpack from the devs might scale

This is why I'm really looking into SerpentOS and their moss build system. Kind of like a combination of Nix and AUR. Simple syntax, simple to create packages, atomic.

https://serpentos.com/docs/packaging/

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

> more familiar Linux build systems

What's a 'familiar Linux build system'? make?

They likely mean 'generally used with other languages'. make is an example.

Make is primarily used with C and C++. It is not commonly used in Java, Rust, Go, NodeJS, or hardly anything besides C and C++. Make is not "generally used with other languages".

Java https://github.com/openjdk/jdk/blob/master/Makefile

Rust https://github.com/rust-lang/rust/blob/master/tests/run-make...

Go https://github.com/golang/go/blob/master/src/runtime/Makefil...

NodeJS https://github.com/nodejs/node/blob/main/Makefile

OCaml https://github.com/ocaml/ocaml/blob/trunk/Makefile

Python https://github.com/python/cpython/blob/main/Makefile.pre.in

Haskell https://github.com/ghc/ghc/blob/master/ghc/Makefile

R https://github.com/wch/r-source/blob/trunk/Makefile.in

CLR https://github.com/mono/mono/blob/main/Makefile.am

Ruby https://github.com/ruby/ruby/blob/master/enc/Makefile.in

This doesn't prove anything at all. Of course the toolchain has to be built somehow. Some toolchains use make to do that, rather than depending on the previous version of the toolchain's build system. Some toolchains are written in a language completely separate from their downstream language, so they obviously wouldn't be compatible with their own toolchain.

Downstream projects in these languages do not typically use Make.

More to the point, I clicked on the Go one, and it's just including this tiny "Make.dist" file that does nothing except invoke "go tool": https://github.com/golang/go/blob/master/src/Make.dist

Wow. So useful.

I clicked on the Rust one, and not only did it seem to be specific to some old testing infrastructure, but I found this note:

> There are two kinds of run-make tests:

> The new rmake.rs version: this allows run-make tests to be written in Rust (with rmake.rs as the main test file).

> The legacy Makefile version: this is what run-make tests were written with before support for rmake.rs was introduced.

So, it's an obsolete system that is being migrated away from.

But, again, the main point is that what the toolchain does with its free time has little to do with how end user applications are developed, and the complaints in this thread were strictly about building applications in distros, not about building toolchains.

If an application in one of these languages uses make, it is typically just a little syntax sugar around the toolchain commands, which does absolutely nothing to absolve the project of the complaints Linux distro maintainers have about how dependencies are managed.

In case you're not trolling (and it's really hard to tell), those makefiles are for building projects whose source code is written using C or C++. The projects they are building are things like the Java runtime, Go runtime, or the Rust compiler, but they are not building projects whose source code is written in Java, or Rust, or Go etc...

What people are claiming is that make is used as a build system for projects whose source code is written in C or C++.

Make is the common denominator in most projects I come across regardless of language. I see lots of frontend projects and certainly Go and Rust projects using Make quite often.

Ironically many modern C/C++ projects use Cmake to generate Makefiles. If anything the inverse of your observation is mine.

Are those Makefiles doing anything more than calling "go build" and "cargo build"?

Because if they're still using the language-specific build tools and dependency management systems, then I think you would find that the Fedora maintainer higher in this thread would not be any happier that there is a sugar coating of Make. That's not what they're asking for, based on other rants I've seen from Linux distro maintainers.

The barebones ones do exactly what you mentioned: simple calls to the canonical build tool.

The more complex ones at $JOB actually do some caching, dependency management, code generation, and compilation.

I build my OCaml stuff with `make`. I use `dune` only for libraries, because it makes installing them super easy.

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.

> This rant more or less equally applies to other language-specific build systems.

And yet those language-specific build systems are overwhelmingly winning, in pretty much every language.

> As Fedora packager for OCaml packages,...

I honestly think traditional Linux packaging is in the wrong here and the problems are essentially self-inflicted (not in the sense that individual maintainers are doing something wrong, but in the sense that the policy that traditional Linux distributions are following is inherently unsustainable. It's designed for a pre-CPAN world)

> 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 base written in another language).

True up to a point, but frankly the worst case is falling back to a terrible C-style build, and "always do terrible C-style builds in case you need to integrate with C code" is not a proposition that has much appeal.

Much as I wish the whole world would standardise on Maven or Cargo, I can't see a realistic path to there without first eliminating C, because the C people are never going to agree to follow a standard for package repositories.

> As Fedora packager

The issue is there. Not you or your fellow packagers of course, but in the idea that every linux distribution needs it's own packaging system, and each version of a distribution it's own packages.

Reply on news.ycombinator.com