|
From: | Jef Driesen |
Subject: | Re: Public header files |
Date: | Wed, 17 Mar 2010 13:23:09 +0100 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 |
On 16/03/2010 14:22, Peter Johansson wrote:
On 3/16/10 8:29 AM, Jef Driesen wrote:On 15/03/2010 22:18, Ralf Wildenhues wrote:* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:I suppose you are referring to solutions like this: m4_define([mylib_version_revision],m4_esyscmd([my_revision_script])) where the revision script fetches the revision from the SCM system, or from a version file when using tarballs.Well, that solution has the disadvantage that a revision change causes a full autotools and configure rerun, but yes, that is one suboptimal solution.Is there a better method?Which method to use depends on where you want the MY_REVISION_VERSION to propagate. Do you need it in any Makefiles, e.g., or do you only need it compiled into your program.
I only need it compiled into my library. The goal is that an application using my library can report the exact revision of the library (for diagnostic purpose).
With the solution I outlined in my previous posts, I can already get the "normal" version info (e.g. the major.minor.micro numbers) into a public header file to allow for compile time version checking. Runtime version checking can easily be achieved by adding a mylib_get_version() function to the library. But when building not yet released code, it's more useful to know the exact SCM revision, rather than the version numbers.
[Prev in Thread] | Current Thread | [Next in Thread] |