[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Public header files

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: 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:


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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]