3 ms·

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 versi

by neilv 3y ago

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.

alerighi 3y ago
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.
- PhilipRoman 3y ago
  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.
fanf2 3y ago
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.)
rjsw 3y ago
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.
- bananskalhalk 3y ago
  Or just the hash from the blob of the file.
GauntletWizard 3y ago
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.

by neilv 3y ago

alerighi 3y ago

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.

PhilipRoman 3y ago
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.

fanf2 3y ago

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

rjsw 3y ago

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.

bananskalhalk 3y ago
Or just the hash from the blob of the file.

GauntletWizard 3y ago

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.