[Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

Jan Vesely jan.vesely at rutgers.edu
Thu Nov 1 16:03:18 UTC 2018


On Wed, 2018-10-31 at 18:40 +0000, Emil Velikov wrote:
> On Wed, 31 Oct 2018 at 17:41, Jan Vesely <jan.vesely at rutgers.edu> wrote:
> > On Wed, 2018-10-31 at 17:22 +0000, Emil Velikov wrote:
> > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer <michel at daenzer.net> wrote:
> > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > > > On Wed, 2018-10-31 at 13:30 +0000, Emil Velikov wrote:
> > > > > > From: Emil Velikov <emil.velikov at collabora.com>
> > > > > > 
> > > > > > The option has been long superseded with LLVM_CONFIG.
> > > > > > Distributions have been using it for a couple of years now.
> > > > > 
> > > > > I've been using it in my configure setup.
> > > > 
> > > > Same here.
> > > > 
> > > Have you tried LLVM_CONFIG, does it not work on your setup?
> > > Alternatively can you update the your scripts, I can provide a patch
> > > if you prefer.
> > 
> > I'm testing mesa/clover for llvm-{5,6,7,git} on three machines, before
> > I start migrating all that setup I wanted to know if a capability is
> > lost and I should start rewriting the scripts or a simple reconfigure
> > in build directories is enough.
> > 
> No capability is lost here.

It is loosing capability to remember configuration. see below.

> 
> > > Even Debian (which I personally consider fairly conservative) has been
> > > using it for a minimum of two years.
> > > https://salsa.debian.org/xorg-team/lib/mesa/commit/436b3472adde14b22e9ce204820dab417cfe00c6
> > 
> > I'm sorry. This is completely irrelevant. I don't care what distros
> > use, I build from source.
> > 
> 
> <being silly>
> Hope you don't do the whole distro...
> 
> Although I guess I'm may be an exception by keeping an eye what "my"
> distro does ;-)
> </being silly>

Why the mockery? do you not build libraries you work on?
OpenCL programs can run into issues in either mesa or llvm or libclc.
The last one was/is in the relatively worst shape so most of the effort
goes there. Since distros don't offer multiple mesa packages built
against different LLVM versions I need to build from source.

> > > > > This might be a stupid question; is the LLVM_CONFIG env var remembered
> > > > > between reconfigure (touch configure.ac; make) or do I need to provide
> > > > > it explicitly every time configure is run?
> > > > 
> > > > I don't know the answer, but agree that would be a minimum requirement
> > > > for this change.
> > > > 
> > > Nope, yet it's not really a minimum. LLVM_CONFIG has been around for
> > > years, it will work for any Mesa checkout since its inception.
> > > You can safely bisect Mesa and things will just work.
> > 
> > The question is; Do I have to do "LLVM_CONFIG=..." make every time
> > bisect changes configure.ac?
> > 
> You can do (although there's other options if this one seems weird)
> 
> $ LLVM_CONFIG=... ../autogen.sh

That does not answer my question.

suppose the following sequence:
$ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh
...
        llvm:            yes
        llvm-config:     /usr/local/llvm-4/bin/llvm-config
        llvm-version:    4.0.1
...
$ make -j128
$ touch ../mesa-src/configure.ac
$ make -j128
...
        llvm:            yes
        llvm-config:     /usr/bin/llvm-config
        llvm-version:    7.0.0
...

the second reconfigure silently reverted back to system default llvm.
That's a loss of capabilty for me.
Why was it even moved to env var? what's the problem with having "
--with-llvm-config" (or with-llvm-prefix) configure option?
Why should the build system be focused on distros (with custom
packaging scripts) over those who build from source?

Jan

> HTH
> Emil

-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181101/39c4f797/attachment.sig>


More information about the mesa-dev mailing list