Unix version control lore: what, ident
1–10 of 29 posts
Re: Unix version control lore: what, ident
#2I 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.
Re: Unix version control lore: what, ident
#3I 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.
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.
Re: Unix version control lore: what, ident
#4I 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.
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.)
Re: Unix version control lore: what, ident
#5I 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.
For Git, you could embed a string of the form:
:path/in/repo/to/file.ext
Re: Unix version control lore: what, ident
#6I use absolute overkill for this. A `build.rs` file that persists a metadata file into `OUT_DIR`. Something simpler would be nice, for sure.
Re: Unix version control lore: what, ident
#7I 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.
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 po…
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.
Re: Unix version control lore: what, ident
#8Golang 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.
Re: Unix version control lore: what, ident
#9Relatedly, 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...
Re: Unix version control lore: what, ident
#10I use absolute overkill for this. A `build.rs` file that persists a metadata file into `OUT_DIR`. Something simpler would be nice, for sure.