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

[Jonathan Gray]

On Tue, Sep 23, 2014 at 12:38:55AM +0100, Emil Velikov wrote:
> 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 :)

Both autoconf and cmake builds of LLVM install llvm-config,
and llvm-config from 3.4.2 for example does report the correct
version unlike the header method when built via cmake.

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

It seems the general sentiment is to remove the autoconf build system
in LLVM.  See
http://comments.gmane.org/gmane.comp.compilers.llvm.devel/69072
FreeBSD has their own LLVM build system, but likely still build
llvm-config.  The OpenBSD LLVM port switched to building with
cmake for LLVM 3.0 about three years ago, I'm not entirely sure
on the reasons for that.