I have some embedded C software stored under TFS and also have a corresponding TFS build definition that successfully checks out the code and builds it using the relevant compilers. So just to be clear, although this is TFS, I'm not building a .NET application.
Now that I have the build working, I'm trying to provide overall software versioning support which should be linked to the build process. My current aim is as follows:
The source code that is being built has a header file that has #defines for three variables, Major Version, Minor Version and Build Number. This header file is then used to baked the version number in to the software at compile time. The concept is that the developer is responsible for updating only the major and minor version numbers as part of the development. The build number always remains at 0 in the source and should not be modified by the developer.
In the instance that a developer produces a build locally on their own machine, the major and minor version will be set as defined in the code, but the build number will remain at 0 which gives an indication of a non-controlled build. However, for official builds on the server, I'd like TFS to increment the build number automatically, so that subsequent builds with the same major and minor version specified, result in an increment of the build number to provide an overall unique version descriptor.
After doing a bit of reading, how I specifically see this working is to define the TFS build number format as something like the following: $MajorVersion.$MinorVersion.$(Rev:.rr) where MajorVersion and MinorVersion are variables that I define as part of the build process.
I realized that the revision maintains uniqueness based on the entire build number format. So I thought it was vital that I extract the major and minor versions from the source code and populate the two build variables prior to trying to evaluate the revision and wider build number. I've created a Powershell script to extract the major and minor versions from the header file using regular expressions and then set the variables from within the script.
Now finally to the problem. It seems my approach is flawed. As soon as I queue the build, the TFS build number is evaluated immediately, seemingly to give a name to the queued build. At this stage, I've been unable to run my script to extract the major and minor versions and hence also get an incorrect revision number. So based on my previously mentioned build number format above, I end up with a build number and result name of something like "..01" or "0.0.01" depending on whether I initialize the major and minor variables in the build definition.
So can anyone see a way that I can defer the evaluation of the TFS build number until after I've had a chance to read my major and minor verisons from source via a Powershell build step? If I can do this, the revision should be calculated correctly based on the real major and minor versions. I'll then use another script to set only the Build number #define in my header file to match the revision in the TFS build number. Also, as it seems that TFS uses the build number as the name of the queued build, I'm not sure how I can deal with this since I don't know the final TFS build number at the point the build is queued. Can the name be modified during the build process?
Please help. I think my idea is fairly simple but I'm struggling to make it happen with the otherwise very good TFS 2015 build system.
