Hacker News Reader

Comment by neilv | Hacker News Reader

I used to use these embedded version strings, and occasionally they were very helpful.

As the article says, it's not as easy a fit for Git.

The embedded version etc. strings could also make reproducible builds slightly more tricky than they already are.

Even if they're not worth the trouble for current software, they could be a big timesaver for archaeology/reconstruction of old software.

View on HN

It should be safe for reproducible builds because the version strings come from the commit metadata, so they are fixed for a given version of the code.

(My scripts have some cruft for marking builds from dirty source trees, in which case they are not reproducible – but in that case it’s OK.)

For Git, you could embed a string of the form:

  <git commit id>:path/in/repo/to/file.ext

to be able to retrieve the exact source file contents used to build something.

Or just the hash from the blob of the file.

I think that Git solves an imporant problem that those embedded version strings didn't - Git commits are guaranteed to be either unique or dirty. Generating a summary of your repository state should be done early, and included exactly in the artifacts, as should build flags. Google's internal build system included a bunch of build server information, including build time and build host, but importantly it included these variables in every built package as a simple .env file. This env file would cause the build system to "falsely" report all of these things, so you had a reproducible build, even with uniquifying data embedded.

I also used this mechanism more than one time on embedded project. Define a static variable with some metadata of the firmware and markers, such that tools (e.g. tools to perform an update) can, by simply using a regex on the binary file (that is a couple of kb at most) get metadata on the file, such as the version. This way you don't need to add another file header around the raw binary, something it's not always possible.

haha I've been bitten often enough by complex build systems (cough Yocto cough) to develop a habit of adding random strings to see what actually gets included in the final executable. When you have patches, patches patching other patches, hundreds of ifdefs and python mixed with shell scripts, it is often the only way to make sense of it all.

Reply on news.ycombinator.com