[HN Gopher] Unix version control lore: what, ident
___________________________________________________________________
Unix version control lore: what, ident
Author : todsacerdoti
Score : 61 points
Date : 2024-05-13 16:17 UTC (6 hours ago)
(HTM) web link (dotat.at)
(TXT) w3m dump (dotat.at)
| neilv wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| GauntletWizard wrote:
| 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.
| renewiltord wrote:
| I use absolute overkill for this. A `build.rs` file that persists
| a metadata file into `OUT_DIR`. Something simpler would be nice,
| for sure.
| fanf2 wrote:
| You might like https://docs.rs/git-version/latest/git_version/
| or https://docs.rs/git-testament/latest/git_testament/
| stevekemp wrote:
| Golang binaries embed the version of the compiler into them, and
| can easily add git revision information too.
|
| That's a nice feature for adding "foo -version", or similar, to
| show the users what their binaries were built from.
| fanf2 wrote:
| Here's a nice blog post with more information about that
| https://blog.carlana.net/post/2023/golang-git-hash-how-to/
| puetzk wrote:
| Relatedly, GCC/binutils still has a `.ident` assembly directive
| (https://sourceware.org/binutils/docs/as/Ident.html) and `#ident`
| preprocessor command (https://gcc.gnu.org/onlinedocs/cpp/Other-
| Directives.html) that emit data into an ELF .comment for `what`
| to read...
| wpollock wrote:
| The original name was .SCCS. I put the SCCS strings in there to
| save memory. In the early 1980s, the 3B20 computers used to
| manage the U.S. phone network had a 32MiB memory limit. By 1985
| the network had outgrown that memory limit, by just a few
| kilobytes. So I hacked the C compiler to look for #(*) strings
| and put them into .SCCS rather than .data. Since .SCCS didn't
| load into memory by default, I saved just enough to run one
| more process! Each binary was built from about 2,000 source
| files, so those strings added up to a significant amount of
| memory.
|
| This was at Bell Labs Columbus Ohio. Also, I think it was COFF
| and not ELF. Used System V r2.
| paradox460 wrote:
| Years ago, when moving off svn to git, I cursed the fact that
| there was no such string replacement feature. I understand why it
| doesn't exist, but when it was an obstacle to my job, I loathed
| it.
|
| It was easy enough to replace with a short script, and I use a
| variation of that to this date
| ggm wrote:
| FreeBSD finally removed the last of the $Id$ in the source some
| months ago. I don't entirely know why they were so keen to do
| this but I'm sure they had a reason.
|
| I don't see this, or binary .ident strings as e.g. clashing with
| idempotent builds.
___________________________________________________________________
(page generated 2024-05-13 23:00 UTC)