path: root/version.c
AgeCommit message (Collapse)Author
2008-10-21make libhugetlbfs_version file staticAndy Whitcroft
Signed-off-by: Andy Whitcroft <apw@shadowen.org> Acked-by: Adam Litke <agl@us.ibm.com> Acked-by: Mel Gorman <mel@csn.ul.ie>
2006-09-21build: Add version string to all built objectsaglitke
Due to the rapid development of libhugetlbfs, we've had requests to stamp binaries with a version, so that there is an easy way to tell exactly which source code a particular libhugetlbfs binary came from. How does it work. The idea is that we have two things, a base version in 'version' and a current version string in 'version.h'. The base version is the version as it appears in your git repository and is based of tags. The version string (as well as being C digestable) is the base version with the local modification state appended. We have two main modes of operation, inside and outside a git repository: When in a git repository the version file is maintained directly from the git branch we are on. The version will be one of three things: where there is a tag on this revision it will be that tag (v0.1); where there is a tag 'nearby' it will be that tag plus and 'offset' (v0.1+g123456768); lastly where there is no tags at all, it will be the full sha1 for this commit. Obviously it will generally be one of the first two, and for a full release going out we'd expect it to be the first (a full tag). If git views the working copy as modified relative to HEAD then that will trigger a (modified) marker in the version.h. When not in a git repository the version file is a static marker and used as the base version, the date of this file is also used as the modification marker for the repository. If any of the profered source files are newer then we assume the working copy is modified and similarly trigger a (modified) marker in the version.h. Signed-off-by: Adam Litke <agl@us.ibm.com> Signed-off-by: Andy Whitcroft <andyw@uk.ibm.com>