[Mesa-dev] [PATCH 0/4] configure.ac: LLVM again!

Marek Olšák maraeo at gmail.com
Wed Feb 1 19:36:16 UTC 2017


On Wed, Feb 1, 2017 at 7:52 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 1 February 2017 at 17:32, Marek Olšák <maraeo at gmail.com> wrote:
>> On Wed, Feb 1, 2017 at 3:04 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 29 January 2017 at 23:13, Marek Olšák <maraeo at gmail.com> wrote:
>>>> On Sun, Jan 29, 2017 at 11:14 PM, Tobias Droste <tdroste at gmx.de> wrote:
>>>>> Am Sonntag, 29. Januar 2017, 22:31:55 CET schrieb Marek Olšák:
>>>>>> On Sat, Jan 28, 2017 at 9:29 PM, Tobias Droste <tdroste at gmx.de> wrote:
>>>>>> > Am Samstag, 28. Januar 2017, 16:09:29 CET schrieb Marek Olšák:
>>>>>> >> On Sat, Jan 28, 2017 at 3:31 PM, Ilia Mirkin <imirkin at alum.mit.edu>
>>>>> wrote:
>>>>>> >> > Can you explain why it's a desirable goal to be able to build radv
>>>>>> >> > without
>>>>>> >> > --enable-gallium-llvm? Perhaps it's obvious, but I'm not seeing it.
>>>>>> >> >
>>>>>> >> > On Jan 28, 2017 8:57 AM, "Tobias Droste" <tdroste at gmx.de> wrote:
>>>>>> >> >
>>>>>> >> > This is a reworked series of the previous LLVM related changes to
>>>>>> >> > configure.ac that were reverted due to breaking scons.
>>>>>> >> >
>>>>>> >> > This takes a different approach to the previous series and adds an
>>>>>> >> > extra define for LLVM version checks if RADV is build.
>>>>>> >> >
>>>>>> >> > This allows to build RADV with "--disable-gallium-llvm".
>>>>>> >> >
>>>>>> >> > Patch 1, 2 and 3 are the same as in the previous series, just rebased.
>>>>>> >> > The new stuff is in patch 3.
>>>>>> >> >
>>>>>> >> > Tobias Droste (4):
>>>>>> >> >   configure.ac: Rename MESA_LLVM to FOUND_LLVM
>>>>>> >> >   configure.ac: Only set LLVM_LIBS if LLVM is used
>>>>>> >> >   configure.ac: Separate HAVE_LLVM defines for gallium and radv
>>>>>> >> >   configure.ac: Don't check LLVM version in gallium_require_llvm
>>>>>> >>
>>>>>> >> I fail to see how 2 HAVE_LLVM definitions can be a good idea.
>>>>>> >>
>>>>>> >> Enabling LLVM by default and allowing people to use --disable-llvm
>>>>>> >> should be enough for everybody.
>>>>>> >
>>>>>> > I don't want this too and there's an obvious easier and better solution to
>>>>>> > this, but it was NAKed by Jose, because it changed 6 lines in draw (the
>>>>>> > scons fix is easy):
>>>>>> > https://lists.freedesktop.org/archives/mesa-dev/2017-January/141263.html
>>>>>>
>>>>>> The link doesn't contain Jose's NAK. He only said that it had broken
>>>>>> the scons build, and asked you to wait for his review next time.
>>>>>
>>>>> It's just the start of the thread. It's over multiple mails.
>>>>>
>>>>> https://lists.freedesktop.org/archives/mesa-dev/2017-January/141897.html
>>>>> "2) you're keeping things nice and neat for yourselves by shoving the
>>>>> ugly bits (like this weird USE_LLVM_FOR_DRAW/HAVE_GALLIUM_LLVM) into
>>>>> draw/gallivm/llvmpipe, which I simply cannot and will never accept."
>>>>
>>>> I don't really care about this stuff too much, but I think adding more
>>>> HAVE definitions for LLVM sounds like a bad idea, and allowing
>>>> building radv (with llvm) + softpipe (without llvm) is a use case that
>>>> won't have any users IMO.
>>>>
>>> Having a generic --enable-llvm was suggested by Tobias and Ilia (et al) iirc.
>>> Doing that leads to a small functionality change - building gallium
>>> w/o LLVM + radv anyone ?
>>>
>>> Regardless we might give it a try for 17.1 and see if/for how many
>>> people that is an issue.
>>> For the moment we'll just resolve all the [quirky] combinations to build.
>>
>> Why do you wanna build Gallium without LLVM + radv?
>>
> I was wondering about the same thing.
>
> Then again it's allowed atm, plus is/was working like a charm (with
> the bug addressed).
> We can change/fix that for 17.1.x, but I'd keep expectations
> consistent within the feature freeze.

I think that the option to build Gallium without LLVM + radv with LLVM
should be dropped. If it works now, whatever, but it's a useless
combination to me. Other than that, softpipe should never be used by
ordinary users.

Marek


More information about the mesa-dev mailing list