Re: [fossil-users] A scheme to insert the Fossil checkin ID into a built executable
On Tue, Jun 28, 2016 at 1:34 PM, Warren Young wrote: > > 5. My scheme modifies one of the input source files — as opposed to > modifying the built executable, as in Ron W’s scheme — which means you > could have an executable that claims to be built against the prior checkin > on the current branch instead of the current checkin. That is, if you edit > a file, build the software, test it, and then check the change in, the > checkin ID containing the change doesn’t match the checkin ID in the > executable until you build again. > As I mentioned in my post, our build system does a commit in the post link phase of the build, so the ID embedded in the executable matched the commit. I know some people don't like committing untested code, but our team follows a "commit early, commit often" philosophy. We do, for the most part, commit only code that compiles and links. Also, we have the option to do "debugger only" builds, which don't do the commit, and generates an executable that can only run with the debugger. Builds that are to be run without the debugger get programmed in to electronic modules. Because the modules can be picked up and taken away, it's very important we are able to identify the software in them. (We have a special tool to do that.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] A scheme to insert the Fossil checkin ID into a built executable
A recent post[1] mentioned one scheme for inserting the Fossil checkin ID for the sources used to build a given executable into the executable itself, for various good reasons. I have a similar scheme, which I thought I’d present here. This shell script is executed at the end of each successful build: #!/bin/bash PATH=/bin:/usr/local/bin srcdir="$(dirname "$0")"/../src revfile="$srcdir/revision.fs" rev=$(fossil info | grep ^checkout: | cut -c 16-24) if [ -r "$revfile" ] then oldrev=$(grep -o '"[0-9a-f]\+"' "$revfile" | tr -d \") if [ -n "$oldrev" ] && [ $oldrev = $rev ] then # Revision is unchanged, so don't touch the file exit 0 fi fi cat > "$revfile" < Properties > Build Events > c:\cygwin64\bin\bash -c ../../../tools/genrevfile The above relative path may need adjustment in your build system. The CWD at build time under Visual Studio 2015 seems to be the build target directory; e.g. bin/Debug, so you need at least 3 levels of .. to get up to the top level of the project if your sources are one level deep in the project directory. If you were thinking you’d try this with Microsoft’s new experimental “Bash on Windows” add-on for Windows 10 to avoid having to install Cygwin, don’t bother. Native Windows apps can’t call WSL apps due to the way NT subsystems work. WSL can’t replace all uses of Cygwin. 4. The script doesn’t replace the revision source file if it sees that the current checkin ID is the same as the one in the file in order to avoid triggering a needless rebuild. 5. My scheme modifies one of the input source files — as opposed to modifying the built executable, as in Ron W’s scheme — which means you could have an executable that claims to be built against the prior checkin on the current branch instead of the current checkin. That is, if you edit a file, build the software, test it, and then check the change in, the checkin ID containing the change doesn’t match the checkin ID in the executable until you build again. This is not a problem in my development practice because debug executables never leave the build system except for temporary on-site testing, and release executables are built in a separate step after the sources for that release are all checked in. Thus, the only case where we actually want this checkin ID — a long-released executable, which we need to match up with a particular source revision — always has the embedded checkin ID properly matched with the source that generated it. 6. If your build system has some kind of bootstrapping provision (as is common with the GNU autotools, for example) you should call this script from that bootstrap script, since bootstrapping is normally the first thing done to a fresh Fossil checkout. Otherwise, you need to run this script once by hand, else the first build will fail due to the missing source file. [1]: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23535.html ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
