4 ms·

I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com https://buckbuild.com [2] h

I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com https://buckbuild.com [2] https://buckaroo.pm https://buckaroo.pm

philippnagel 9y ago
Also interesting: https://bazel.build/ https://bazel.build/
- yorwba 9y ago
  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.
moosingin3space 9y ago
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.
- entelechy 9y ago
  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 ?
- entelechy 9y ago
  why I'm consider that using pkg-config in buck may break reproducibility: https://github.com/facebook/buck/issues/1430 https://github.com/facebook/buck/issues/1430
sfrigon 9y ago
Is there any known problems / pitfalls regarding cmake and reproducible builds? Just curious to know.
- jwilk 9y ago
  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-builds/Week-of-Mon-20160905/006984.html https://lists.alioth.debian.org/pipermail/reproducible-build...
guipsp 9y ago
^CEO of LoopPerfect, which maintains Buckaroo Might want to disclose that.
geofft 9y ago
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 :)
- rstuart4133 9y ago
  > 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.
  - geofft 9y ago
    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.)

I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com https://buckbuild.com [2] https://buckaroo.pm https://buckaroo.pm

philippnagel 9y ago

Also interesting: https://bazel.build/ https://bazel.build/

yorwba 9y ago
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.

moosingin3space 9y ago

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.

entelechy 9y ago
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 ?
entelechy 9y ago
why I'm consider that using pkg-config in buck may break reproducibility: https://github.com/facebook/buck/issues/1430 https://github.com/facebook/buck/issues/1430

sfrigon 9y ago

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

jwilk 9y ago
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-builds/Week-of-Mon-20160905/006984.html https://lists.alioth.debian.org/pipermail/reproducible-build...

guipsp 9y ago

^CEO of LoopPerfect, which maintains Buckaroo Might want to disclose that.

geofft 9y ago

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

rstuart4133 9y ago
> 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.
- geofft 9y ago
  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.)