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

[Tobias Droste]

Mit freundlichen Grüßen
Tobias Droste

Am Mittwoch, 18. Januar 2017, 18:12:37 CET schrieb 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.

Nothing for LLVMPIPE will change and no code in gallivm will change. 

This is only for gallium code shared by all drivers that has optional LLVM 
codepaths (and this is right now only the case for the files from the commit).
It's not changing gallivm but it enables/disables its use in auxillary/draw.
llvmpipe is not touched at all.

> 
> 
> Jose