31–40 of 45 posts
nix fixes this had to be said
(Fyi I just used something like the solution from the article, with the hash embedded in the binary image to be burned to ROM masks. The gaps in toolchain versioning and not building with dirty checkouts can be managed with self discipline /internal checks)
https://github.com/xrootd/xrootd/blob/master/cmake/XRootDVer...
and also the genversion.sh script at the top of the repo.
I use these plus #cmakedefine and git tags to manage the project version without having to do it via commits.
Give Nix a look sometime, it takes this to a whole new level by including all of the build dependencies in the hash, and their build dependencies and so on. The standard flake workflow even includes the warning about having uncommitted files.
nix run github:user/repo/commit
nix fixes this had to be said
Can I build my embedded firmware with nix using a Windows only toolchain? (Fyi I just used something like the solution from the article, with the hash embedded in the binary image to be burned to ROM masks. The gaps in toolchain versioning and not building with dirty checkouts can be managed with self discipline /internal checks)
Earlier quoted context omitted.
Can I build my embedded firmware with nix using a Windows only toolchain? (Fyi I just used something like the solution from the article, with the hash embedded in the binary image to be burned to ROM masks. The gaps in toolchain versioning and not building with dirty checkouts can be managed with self discipline /internal checks)
Generally development tools run fine under wine, so I'd guess it would be fine. Running a windows binary within wine within WSL on windows does seem a little insane tho!
Git hashes have nothing whatsoever to do with whether you can do a clean build of the same tree twice with the same results, bit for bit. Git hashes or tags can help identify what was built: the inputs. You only need to know that for traceability: when you hold the released outputs, but do not hold (or are not sure you hold) the matching inputs. If builds are reproducible, the traceability becomes more meaningful. In…
It's addressing a distinct problem from "if we rebuild any given version, perhaps some later time, do we even get the same binary?" which is what people usually mean by "reproducible builds".
Your tip that injecting build ids can be done with linker flags without needing to generate header files is a great one.
Passing version info without code generation using linker flags can also be done in other languages & toolchains, e.g. with Go projects, the go linker exposes an -x flag that can be used to set the value of a string variable in a package [1] [2].
A step beyond this could be to explicitly build a feature into your software to help the user report bugs or request support, e.g. user clicks a button and the software dumps its own version info, info about what the user is doing & their machine, packages it up and sends in to your support queue. Doesn't make sense doing this for backend services, but you do see support features like this in PC games to help users easily send high quality bug reports.
[1] https://pkg.go.dev/cmd/link
[2] https://www.digitalocean.com/community/tutorials/using-ldfla...
Git hashes have nothing whatsoever to do with whether you can do a clean build of the same tree twice with the same results, bit for bit. Git hashes or tags can help identify what was built: the inputs. You only need to know that for traceability: when you hold the released outputs, but do not hold (or are not sure you hold) the matching inputs. If builds are reproducible, the traceability becomes more meaningful. In…
Yep, your way of framing it is clearer. Embedding version information in released binary artefacts helps answer the question of "what version of the software even produced this output/is crashing in production?". This is the problem that the author is focusing on, and it is an important thing to sort out early in any serious project, especially if you ship software that gets deployed to customer machines. Setting thi…
Which golfs to "traceable" != "reproducible"
Git hashes have nothing whatsoever to do with whether you can do a clean build of the same tree twice with the same results, bit for bit. Git hashes or tags can help identify what was built: the inputs. You only need to know that for traceability: when you hold the released outputs, but do not hold (or are not sure you hold) the matching inputs. If builds are reproducible, the traceability becomes more meaningful. In…
Yep, your way of framing it is clearer. Embedding version information in released binary artefacts helps answer the question of "what version of the software even produced this output/is crashing in production?". This is the problem that the author is focusing on, and it is an important thing to sort out early in any serious project, especially if you ship software that gets deployed to customer machines. Setting thi…
Someday, Go programs won't have to do this: https://github.com/golang/go/issues/50603
We used the same trick (git hash + git diff to monitor uncommitted changes) in a Python simulation framework we are developing for the JAXA/EU space mission "LiteBIRD." [1]
[1] https://iopscience.iop.org/article/10.1088/1475-7516/2025/11...
That barely scratches the surface when it comes to reproducible c and c++ builds. In fact the topic of reproducible builds assumes your sources are the same, as in that's really not the problem here. You need to control every single library header version you are using outside your source like stdlibs, os headers, third party, and have a strategy to deal with rand/datetime variables that can be part of the binary.
How would you even start solving these?