Hacker News Reader

Hacker News

Comment by entelechy | Hacker News Reader

Parent Full thread

entelechy

I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility.

[1] https://buckbuild.com

[2] https://buckaroo.pm

View on HN

^CEO of LoopPerfect, which maintains Buckaroo

Might want to disclose that.

Is there any known problems / pitfalls regarding cmake and reproducible builds? Just curious to know.

cmake uses absolute paths almost everywhere.

This is a big problem if you want reproducible builds with varying build directory.

https://lists.alioth.debian.org/pipermail/reproducible-build...

Well, this is Debian - they generally don't maintain the software, they just package it. Small changes can be pushed upstream, but "Here's a brand new build system that we promise is super cool" is generally not a patch that people like taking :)

> Well, this is Debian - they generally don't maintain the software

They definitely maintain software. There is a whole pile of packages that aren't maintained upstream any more that are still maintained in Debian, they write things like manual pages for commands that don't have then, they bash the build scripts into something that works on a whole pile of architectures the author never considers, they manage what is probably the worlds biggest issue track system, and then there is the security team producing patches for versions upstream no longer supports.

But probably it's just your wording. While they do maintain software, they are mostly concerned with packaging existing software, not writing new stuff.

They generally don't maintain the software. Things like manual pages and architecture porting can be pushed upstream, and are fine to maintain as diffs if not; buildsystem changes are usually hard, and maintaining that as a delta makes it hard to incorporate new versions.

(One of the packages I maintain in Debian is apparently dead upstream as of the last year or so, but even so I'm not very interested in becoming the new upstream and adopting big changes like a new build system.)

Based on the experiences of systemd, gtk, and X11 in switching to Meson, I'd think Meson might be the best choice here. While Buck, Bazel, Pants, etc. are designed for large projects, Meson is designed for small-to-medium-size projects and integrates with pkg-config, which in turn should provide simpler integration with distribution package managers. My experiences with Bazel demonstrated that integration with distribution packages can be quite difficult.

why I'm consider that using pkg-config in buck may break reproducibility: https://github.com/facebook/buck/issues/1430

Although never mentioned, you can use pkg-config with buck by embedding your pkg-config command into the compiler flags eg.:

cxxflags = ${pkg-config opencv python --cflags --libs}

Furthermore I don't see the reason why you woudn't use buck for small projects. What makes you think buck is less suitable for small projects ?

Also interesting: https://bazel.build/

Funny that you should mention bazel on the topic of reproducible builds. When I last used it to build TensorFlow, the build was very much not reproducible. I took me three rebuilds with same flags to finally get GPU support compiled in.

Reply on news.ycombinator.com