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" <<EOF
namespace myprogram
module revision =
let current = "$rev"
EOF
The script has the following features:
1. The PATH change at the top is just paranoia. No sense using a broader PATH
than is actually required. You might need to add /usr/bin if you’re using an
OS-provided fossil binary.
2. The srcdir path will need adjustment in your build system. The example
presented here assumes a scheme where the project sources are in a src subdir
under the main project directory and there is a peer directory to that called
tools, which holds this script, which I’m calling genrevfile.
3. Although this scheme is targeting an F# program, the core of the idea is
trivially portable to most any source language. You just need to change the
output file name on line 4 of the script and change the generated source code
in the heredoc at the end of the script. You’ll also need to change the regex
in the middle of the script if your programming language of choice doesn’t use
double quotes for string literals.
You may be surprised to see a Bash script generating F# code, a programming
language associated with Microsoft. I find shell scripts more powerful than
batch files and easier to write and maintain than VBScript or PowerShell.
Visual Studio lets you call out to Cygwin’s Bash to run this via a custom build
step: Project > 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/[email protected]/msg23535.html
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
