[Mesa-dev] [PATCH 4/6] configure.ac: Set and use HAVE_GALLIUM_LLVM define

[Jose Fonseca]

On 18/01/17 17:51, Tobias Droste wrote:
> Am Mittwoch, 18. Januar 2017, 15:40:22 CET schrieb Emil Velikov:
>> On 18 January 2017 at 15:11, Jose Fonseca <jfonseca at vmware.com> wrote:
>>> I've reverted this and took a closer look.
>>>
>>> I'm fine with autoconf glue doing whatever: HAVE_LLVM -> HAVE_GALLIUM_LLVM
>>> and what not.
>>>
>>> But I'm afraid I can't accept replacing HAVE_LLVM in the .c code, because:
>>> - it breaks the other build systems if not updated
>>> - but above all, it creates merge conflicts in branches, work in progress
>>> changes, etc, as HAVE_LLVM define appears all over the place.
>>>
>>> So, could we please rework the series so .c code is left alone?
>>
>> While I see where you're coming from, the argument of unmerged
>> branches/wip changes is a bit flaky.
>> That aside I fully agree - changing this in Gallium is asking for
>> trouble for the reasons you mentioned.
>>
>> In order to untangle things we want to have a distinction between the
>> gallium (gallivm afaict) and other users - RADV presently.
>> So how about we update the RADV instances and ensure that the we set
>> the HAVE_{RADV,}_LLVM lot appropriately. Latter will be picky but
>> overall things should work w/o annoyances that HAVE_GALLIUM_LLVM
>> brings ?
>
> Hi Jose,
>
> sorry for breaking things on your side!
>
> As Emil said, this is only needed for gallivm because LLVM is optional there
> and adding HAVE_GALLIUM_LLVM to the other build systems shouldn't be too hard.
> I would prefer to go this route and leave the .c files changed but update all
> build systems.
> Scons? Android? Something I'm missing?
>
> If you're not working on anything in src/gallium/auxiliary/draw/ that has
> something todo with LLVM you won't get any conflicts or other annoyances.
>
> Tobias

I have a strong wish to keep HAVE_LLVM as is in gallivm/llcmpipe .C 
files.  Better rephrase this: unless somebody can present me an argument 
along the lines "there's no other practical solution", then it's not 
even worth considering.


There are experimental llvmpipe branches on 
https://cgit.freedesktop.org/~jrfonseca/mesa , private branches 
elsewhere, all with lots of code using HAVE_LLVM.
It might not mean much or make much sense to others, but trust me, from 
where I'm staying, renaming HAVE_LLVM will be a lot of hassle.  So I'll 
need strong arguments.


Futhermore, llvmpipe is the oldest code and the first to use HAVE_LLVM.

I honestly don't even understand why we'd want to build parts of the 
tree with LLVM while hiding LLVM from other components.  We can't we 
just build everything with LLVM and avoid this combinatorial explosion 
of wierd options that are nothing more than yet another way the build 
can break!!?

But if a separate option is truly necessary, have the newcomer pick a 
different name, or something.


Jose