[llvm-commits] PATCH: Add Version.h and macros

[Bill Wendling]

Hi Daniel,

This will require a bit more thought. Right now, we generate Version.h  
when doing an Apple-style build. It looks like:

	#define LLVM_VERSION        1234
	#define LLVM_MINOR_VERSION     3

This patch would conflict. I would like to get Devang's input on this.  
It's possible that a scheme can be developed that will kill two birds  
with one stone. :-)

-bw

On Oct 28, 2008, at 8:34 PM, Daniel Dunbar wrote:

> The attached patch adds llvm/Version.h, which provides the following  
> defines:
>
> LLVM_VERSION_MAJOR, LLVM_VERSION_MINOR - The major and minor LLVM  
> version *numbers*.
> LLVM_VERSION_BRANCH - The LLVM branch. The intent is for this to be  
> blank for released versions or "svn".
> LLVM_API_VERSION - An arbitrary number identifying the API version.
>
> The purpose of these macros is to support clients who wish to be  
> able to compile with different versions of LLVM. We currently have  
> no defines to support this.
>
> The macros are defined in the configure script and need to be  
> manually updated. They are adjacent to the other code which needs to  
> be manually updated; my autoconf foo is not sophisticated enough to  
> derive them from the version string.
>
> The API_VERSION is designed to support this behavior at a finer  
> grained level than releases. Its success depends on a cooperative  
> policy where API changes imply a  bump of this value. I believe  
> Tanya has encourage developers to clearly mark what are API changes,  
> with limited success. Making LLVM_API_VERSION successful requires  
> people (or reviewers) to actively (a) recognize when they make an  
> API change, and (b) bump the value.
>
> Although this requires a bit more care, this has the following  
> benefits:
> (1) API changes are clearly marked; they are commits which update  
> LLVM_API_VERSION.
>
> (2) Reviewing API changes between releases is simplified, the  
> revision log for Version.h can be consulted.
>
> (3) Clients gain additional flexibility in tracking TOT. This has  
> been important for me in the past on the klee project, where I would  
> like to run with a known good LLVM version, but occasionally will  
> test TOT in order to roll that known good version forward. This has  
> historically been a pain since I need to update my code to work with  
> TOT, test it, then roll back my changes if there are issues.
>
> The LLVM_VERSION_* macros are necessary in my opinion. The  
> LLVM_API_VERSION macro can be argued separately if it has opponents.
>
>  - Daniel
> <Version.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits