Reproducible C++ builds by logging Git hashes • Hacker News Board

Re: Reproducible C++ builds by logging Git hashes

#41

Post by spooky_deep » Thu, Nov 20, 2025, 10:28 AM UTC

ikety wrote: post #5

chuckadams wrote: post #3

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.

It's quite odd to me that Nix or something similar like Mise isn't completely ubiquitous in software. I feel like I went from having issues with build dependencies to having that aspect of software development completely solved as soon as I adopted Nix. I absolutely can't imagine not using some kind of tool like this. Feels as vital as VCS to me now.

I can say why I bounced off of Nix.

Lots of package combinations didn’t work and I was not skilled enough to figure out why.

The error messages are terrible.

They don’t provide enough versions of packages. I want Python 3.10.4 exactly. But Nix packages by default only provide 3.10.something

I would love to use Nix everywhere, but it’s just too cumbersome for me.

Re: Reproducible C++ builds by logging Git hashes

#42

Post by ikety » Thu, Nov 20, 2025, 11:53 AM UTC

spooky_deep wrote: post #41

ikety wrote: post #5

Earlier quoted context omitted.

It's quite odd to me that Nix or something similar like Mise isn't completely ubiquitous in software. I feel like I went from having issues with build dependencies to having that aspect of software development completely solved as soon as I adopted Nix. I absolutely can't imagine not using some kind of tool like this. Feels as vital as VCS to me now.

I can say why I bounced off of Nix. Lots of package combinations didn’t work and I was not skilled enough to figure out why. The error messages are terrible. They don’t provide enough versions of packages. I want Python 3.10.4 exactly . But Nix packages by default only provide 3.10.something I would love to use Nix everywhere, but it’s just too cumbersome for me.

Tried Mise?

Re: Reproducible C++ builds by logging Git hashes

#43

Post by MomsAVoxell » Thu, Nov 20, 2025, 12:32 PM UTC

corysama wrote: post #23

MomsAVoxell wrote: post #19

Earlier quoted context omitted.

Virtualization, imho. Every build gets its own virtual machine, and once the build is released to the public, the VM gets cloned for continued development and the released VM gets archived. I do this git tags thing with my projects - it helps immensely if the end user can hover over the company logo and get a tooltip with the current version, git tag and hash, and any other relevant information to the build. Then, if…

Back in the PS2 era of game development, we didn't have much of virtual machines to work with. And, making a shippable build involved wacky custom hardware that wouldn't work in a VM anyway. So, instead we had The Build Machine. The Build Machine would be used to make The Gold Master Disc. A physical DVD that would be shipped to the publisher to be reproduced hopefully millions of times. Getting The Gold Master Disc…

Yes I've seen this technique used effectively a number of times in various forms over the years, including in game companies I've worked at.

The nicest variant was the inclusion of a "build laptop" in the budget for the projects, so that there was a dedicated, project-specific laptop which could be archived easily enough, serving as the master build machine. In one company, the 'Archive Room' was filled with shelves of these laptops, one for each project, and they could be checked out by the devs, like a library, if ever needed. That was very nice.

For many types of projects, this is very effective - but it does get tripped up when you have to have special developer tooling (or .. grr .. license dongles ..) attached before the compiler will fire up.

That said, we must surely not overlook the number of times that someone finds a "Gold Master Disc" with a .zip file full of sources out there, too. I forget some of the more famous examples, but it is very fun to see accidentally shipped full sources for projects, on occasion, because a dev wanted to be sure the project was future proof, lol.

Incidentally, hassles around this issue is one of the key factors in my personal belief that almost all software should be written with scripting languages, running in a custom engine .. reducing the loss surface when, 10 years later, someone decides the bug needs to be fixed ..

Re: Reproducible C++ builds by logging Git hashes

#44

Post by chuckadams » Thu, Nov 20, 2025, 2:49 PM UTC

peterldowns wrote: post #21

chuckadams wrote: post #13

Earlier quoted context omitted.

Mise is pretty nice, I'd recommend it over all the other gazillion version-manager things out there, but it's not without its own weak spots: I tried mise for a php project, neither of the backends available for php had a binary for macos, and both of them failed to build it. I now use a flake.nix, along with direnv and `use flake`. The nix language definitely makes for some baffling boilerplate around the dependenci…

The beauty of mise is that as long as someone is hosting a precompiled binary for you, it's easy to get it. I just repro'd and yeah, `mise use php` fails for me on my machine because I don't have any dev headers. But looks like there's an easy workaround using the `ubi` downloader: https://github.com/jdx/mise/discussions/4720#discussioncomme... or see the first comment on this thread to see a way to explicitly specif…

Nix is just one installer (I steer devs toward Determinate's installer) so technically not super-different from needing Docker. Lots of files in /nix but actually less disk use since the store has much more fine-grained de-duping than container images. Nix is still a big bite though, and for most projects I wouldn't make nix a requirement, but the project in question is itself a build system with reproducibility requirements in its design, so I'm not losing too much sleep over this one. The final artifacts don't depend on Nix anyway.

Re: Reproducible C++ builds by logging Git hashes

#45

Post by chuckadams » Thu, Nov 20, 2025, 2:56 PM UTC

spooky_deep wrote: post #41

ikety wrote: post #5

Earlier quoted context omitted.

It's quite odd to me that Nix or something similar like Mise isn't completely ubiquitous in software. I feel like I went from having issues with build dependencies to having that aspect of software development completely solved as soon as I adopted Nix. I absolutely can't imagine not using some kind of tool like this. Feels as vital as VCS to me now.

I can say why I bounced off of Nix. Lots of package combinations didn’t work and I was not skilled enough to figure out why. The error messages are terrible. They don’t provide enough versions of packages. I want Python 3.10.4 exactly . But Nix packages by default only provide 3.10.something I would love to use Nix everywhere, but it’s just too cumbersome for me.

If the nix ecosystem moved entirely to flakes, you could just point at the flake in python's repo, pin it to the proper commit hash, and job's done. Might result in a lot of extra near-duplicate dependencies in the store, but that's unlikely to affect you at the level of Python. Otherwise yeah, you're stuck with whatever combinations were blessed by nixpkgs at the time, or with writing your own derivation.

And the error messages are ... well, yeah. I don't find the nix language as awful as some do, but it's still a functional language by and for functional programmers, and being lazy, a lot of errors surface in very non-obvious places. Ultimately Nix could use a declarative config format on top of everything, but I'd rather they ironed out the other issues first. Guix seems to be a bit further along there, but its platform options are more limited.