| ▲ | kazinator an hour ago | |
Git hashes have nothing whatsoever to do with whether you can do a clean build of the same tree twice with the same results, bit for bit. Git hashes or tags can help identify what was built: the inputs. You only need to know that for traceability: when you hold the released outputs, but do not hold (or are not sure you hold) the matching inputs. If builds are reproducible, the traceability becomes more meaningful. In the TXR project, have a ./configure option called --build-id. This sets an ID that is appended to the version, which is in the executable. It is nothing by default; not used. It is meant to be useful for people who interact with the code, so they can check what they are running (things can get confusing when you are going back and forth among versions, or making local changes). If you set the build ID it to the word "git", then it is calculated using: I have it rigged in the Makefile that it actually keeps track of the most recent build ID in a little .build_id file. If the build ID changes relative to what is in that file, the Makefile will force a rebuild of the .o files which incorporate the build ID. Also, there is no need to be generating dynamic #include material just for this. A simple -Dsymbol=var option in the CFLAGS will define a preprocessor symbol: | ||