<br><br><div class="gmail_quote">On Tue, Oct 28, 2008 at 10:26 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On Oct 28, 2008, at 9:56 PM, Bill Wendling wrote:<br>
<br>
> Hi Daniel,<br>
><br>
> This will require a bit more thought. Right now, we generate Version.h<br>
> when doing an Apple-style build. It looks like:<br>
><br>
>       #define LLVM_VERSION        1234<br>
>       #define LLVM_MINOR_VERSION     3<br>
><br>
> This patch would conflict. I would like to get Devang's input on this.<br>
> It's possible that a scheme can be developed that will kill two birds<br>
> with one stone. :-)<br>
<br>
</div>Yeah, Bill's right, it would be good to unify these.</blockquote><div><br>Ok. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Also, it seems that it would be reasonable to use make something like:<br>
<br>
#define LLVM_RELEASE_VERSION 24<br>
<br>
For LLVM 2.4 etc?  Is there any specific reason to track branches?</blockquote><div><br>No, there is no particular reason to track branches (especially if LLVM_API_VERSION is adopted). I thought it might make sense to provide the full information given by the PACKAGE_VERSION define autoconf generates. I don't see any particular reason not to provide it.<br>
<br>As far as LLVM_RELEASE_VERSION, I prefer to encode major and minor. What is LLVM_RELEASE_VERSION 210?<br><br> - Daniel<br><br></div></div><br>