[Mesa-stable] [Mesa-dev] [PATCH] configure.ac: detect LLVM patch level when built via cmake

[Emil Velikov]

On 17/09/14 15:37, Jonathan Gray wrote:
> On Wed, Sep 17, 2014 at 07:03:56AM -0700, Tom Stellard wrote:
>> On Wed, Sep 17, 2014 at 09:29:34PM +1000, Jonathan Gray wrote:
>>> On Tue, Sep 16, 2014 at 06:24:40PM -0400, Tom Stellard wrote:
>>>> On Tue, Sep 09, 2014 at 07:56:03PM +0100, Emil Velikov wrote:
>>>>> On 09/09/14 16:26, Tom Stellard wrote:
>>>>>> On Sat, Sep 06, 2014 at 01:43:55AM +1000, Jonathan Gray wrote:
>>>>>>> In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
>>>>>>> LLVM was built via autoconf and not when it was built with cmake.
>>>>>>> Fall back to retrieving the patch level from llvm-config --version to
>>>>>>> handle this case.
>>>>>>>
>>>>>>
>>>>>> We should extract LLVM_VERSION_PATH from $LLVM_VERSION and then we won't
>>>>>> have to worry about which config file it is in.
>>>>>>
>>>>> I believe you meant VERSION_PATCH above ? Indeed that would nice thing to have
>>>>> but I doubt that it will get back-ported to the llvm 3.4 branch.
>>>>>
>>>>
>>>> I mean we should do this in Mesa's configure script.  Something like:
>>>>
>>>> LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed 's/^[0-9]\+\.[0-9]\+\.//g'
>>>
>>> This should be
>>>
>>> LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed -E 's/^[0-9]+\.[0-9]+\.//g'
>>>
>>> $ echo 3.4.2 | sed 's/^[0-9]\+\.[0-9]\+\.//g'     
>>> 3.4.2
>>>
>>> $ echo 3.4.2 | sed -E 's/^[0-9]+\.[0-9]+\.//g'  
>>> 2
>>>
>>> $ echo 3.4.2 | gsed 's/^[0-9]\+\.[0-9]\+\.//g'
>>> 2
>>>
>>> $ echo 3.4.2 | gsed -E 's/^[0-9]+\.[0-9]+\.//g'
>>> 2
>>
>> Which of these examples are *BSD compatible?
> 
> To be compliant with POSIX you can only use + in extended regular expressions
> the use of + in basic regular expressions is apparently a gnu extension?
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html
> 
> Using sed with extended regular expressions via -E is also an extension
> but it would seem a more common one.
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
> 
> In the above examples gsed is the gnu one and sed is the
> Diomidis Spinellis/BSD/OS X sed.  The way the REs are handled
> depends on how REs are implemented in the respective libc versions.
> 
> This is really the same issue you reviewed and pushed a
> fix for in cdb353539c259d5c5137394f6a7b4dafef9a40da except
> there is no 'esed' for EREs with sed.
> 
> So the version with -E should be preferred.  But either way there
> is a problem with versions of llvm that don't have a patch level.
> 
> $ echo 3.4 | sed -E 's/^[0-9]+\.[0-9]+\.//g'   
> 3.4
> 
> so if you want to use sed it should be something like
> $ echo 3.4 | sed -E 's/^[0-9]+\.[0-9]+//g'
> 
> Then check for an empty string and set it zero.
> Or just use 'cut' like the cmake patch did.
> 
> LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3`
> if test -z "$LLVM_VERSION_PATCH"; then
> 	LLVM_VERSION_PATCH=0
> fi
> 
AFAICT the agreement here is to drop the header parsing/searching and
use llvm-config --version (i.e. LLVM_VERSION). And obviously zero out
the patch version when applicable.

Jonathan does this solution work properly with llvm's cmake and/or
autoconf build ? If so can you prep a patch please :)

A worthy mention, this is not the first time llvm's cmake build is
causing problems and I'm not sure how well the llvm people tested it.
Any particular reason to stick with it, or is llvm's autoconf build in a
similar (*BSD unfriendly) state as mesa ?

Cheers,
Emil