llvm dev - May 2009 - [LLVMdev] [PATCH] llvm-config: add svn revision to --version

On 2009-05-18 20:06, Frits van Bommel wrote:
> Xerxes Rånby wrote:
>   
>> Frits van Bommel skrev:
>>     
>>> Benjamin Kramer wrote:
>>>       
>>>> The attached patch modifies the llvm build system (both
autotools and
>>>> cmake) to write the revision into PACKAGE_VERSION:
>>>>
>>>> $ llvm-config --version
>>>> 2.6-71981
>>>>     
>>>>         
>>> I don't think that's enough for LDC; we want to be able to
compare the version
>>> with #if, so we need it to produce something like '#define
LLVM_REV 71981' (i.e.
>>> a raw integer, not a string).
>>>   
>>>       
>> When we build Icedtea shark JIT we use the llvm-config version to make 
>> the icedtea code compatible with api changes in llvm.
>> I belive you are trying to do something similarwith LDC. This can be 
>> done without changing the llvm codebase.
>>
>> I suggest the following:
>> add to the LDC configure.
>>
>> LLVM_CFLAGS="$LLVM_CFLAGS -DLLVM_VERSION=`$LLVM_CONFIG --version |
sed 's/\.//;s/svn.*//'`"
>>
>> this will take the llvm-config --version output and truncates the
versionnumber from
>>
>> 2.6svn to 26
>>
>> now the LLVM_VERSION can be used in your source code like this:
>>
>> #if LLVM_VERSION >= 26
>> /*llvm 2.6 and above compatible code*/
>> #endif
>>
>> #if LLVM_VERSION >= 25
>> // etc...
>> #endif
>>     
>
> That's not precise enough. API changes are introduced in svn all the
time, and
> bugs are fixed (obsoleting workarounds). We currently test for 5 different
trunk
> revisions after 2.5.
>
> Though I suppose a similar technique could be used with the original
version of
> the patch, sed'ing out the revision nr. It'd certainly be less
error-prone than
> the current approach.
I think you don't need to support all trunk revisions.
People using trunk could be told to either update to a certain revision,
or stick to a released version.

This should suffice:

#if LLVM_VERSION >= 25
....
#endif

#if LLVM_VERSION == 26
#if LLVM_REVISION < MINIMUM_THAT_CONTAINS_ALLYOUNEED
#error "Please update to SVN rXYZ"
#else
//code for SVN API
#endif

Best regards,
--Edwin

Török Edwin wrote:
> I think you don't need to support all trunk revisions.
> People using trunk could be told to either update to a certain revision,
> or stick to a released version.
We don't support /all/ trunk revisions, but we don't like to force
upgrades
unless it's really needed so we try to at least support most recent
revisions.

One of the reasons is that not all of our developers use the same trunk 
revision, and recompiling LLVM trunk is not something everyone likes to do once 
a day. (It's nice if you can put it off for a couple of days without things 
breaking)

On May 18, 2009, at 11:35 AM, Frits van Bommel wrote:
> Török Edwin wrote:
>> I think you don't need to support all trunk revisions.
>> People using trunk could be told to either update to a certain  
>> revision,
>> or stick to a released version.
>
> We don't support /all/ trunk revisions, but we don't like to force
> upgrades
> unless it's really needed so we try to at least support most recent  
> revisions.
I agree that this is a really useful thing to support. On side of  
being willing to break APIs is that we should work hard to make people  
with out-of-tree code be able to cope with this, even though we  
shouldn't be afraid of breaking APIs.

The idea of the patch to add the new option to llvm-config sounds  
great to me.  One concern: does an svn up now cause a complete relink  
of all llvm tools?  Ideally, I'd like to see something like this:


$ svn up
u docs/LangRef.html
$ make
... only llvm-config is "rebuilt" ...

-Chris

On Monday 18 May 2009 13:35, Frits van Bommel wrote:
> Török Edwin wrote:
> > I think you don't need to support all trunk revisions.
> > People using trunk could be told to either update to a certain
revision,
> > or stick to a released version.
>
> We don't support /all/ trunk revisions, but we don't like to force
upgrades
> unless it's really needed so we try to at least support most recent
> revisions.
>
> One of the reasons is that not all of our developers use the same trunk
> revision, and recompiling LLVM trunk is not something everyone likes to do
> once a day. (It's nice if you can put it off for a couple of days
without
> things breaking)
There's an easy way to fix these kinds of problems.  Deprecate interfaces
for
one release.  I brought this up before but the idea was quickly shot down.
It's insane to litter your code with #ifdefs based on SVN revisions.

This is exactly the kind of situation that the LLVM community needs to 
address.  Changing APIs is fine.  Ripping out old versions without first
deprecating them for a release causes nightmares all around.

                           -Dave