On 20/01/17 02:48, Emil Velikov wrote:
On 19 January 2017 at 19:26, Tobias Droste <[email protected]> wrote:
Am Mittwoch, 18. Januar 2017, 18:45:04 CET schrieb Emil Velikov:
On 18 January 2017 at 18:12, Jose Fonseca <[email protected]> wrote:
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 ?
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!!?
Sadly the combinatoric explosion has been there for a while. Based on
how well my previous attempts to resolve similar issues (see the
"platforms" topic) I doubt we'll even get to fix that.
But if a separate option is truly necessary, have the newcomer pick a
different name, or something.
That's pretty much what I suggested above. Tobias can you please give it a
try ?
I would rather "fix" the other build systems. (As in just define
HAVE_GALLIUM_LLVM if HAVE_LLVM is defined).
I think there is still a misunderstanding on Joses side on what this really
means. No file in gallivm or llvmpipe will be touched. It's really just
auxilliary/draw and there it's exactly 8 lines that will change.
That's it.
I really fail to see how this will break everything that is being worked on
and cause merge conflicts everywhere.
If you still want the other way, I can do that to, but this will of course
need the same fix in the other build system or we have the same situation we
have now, but with other drivers.
Afaict one point is that the use of HAVE_GALLIUM_LLVM vs HAVE_LLVM is
too subtle. Let's not forget that barring the WIP(?) branches, VMWare
has closed source components. Guess how much fun it will be as
suddenly things fail to build/work properly as they re-sync the code
base. No idea how likely the latter is, but considering Jose (and a
few other VMWare guys) wrote sizeable hunk of that code (and Mesa as a
whole) I'd go with his instinct.
Emil
The HAVE_LLVM->HAVE_GALLIUM_LLVM rename is indeed not as invasive as I
thought.
But I still don't understand why HAVE_LLVM->HAVE_GALLIUM_LLVM is
necessary in draw and not on gallivm/llvmpipe.
People want to build draw with LLVM support, but without
gallivm/llvmpipe? That's impossible.
Or is this because the draw files are the only .c files that are
compiled even when HAVE_LLVM is undefined, so these are the only ones
that get to receive the renaming treatment? That's crazy confusing.
There's no away I can accept that.
Let me make this crystal clear to avoid making this discussion even more
protracted: I will not accept any HAVE_LLVM change in
draw/gallivm/llvmpipe .C/.H source code. Period.
HAVE_LLVM used to mean, "whole Mesa being built with LLVM". Now people
want to build something (no idea what yet to be honest) with LLVM, but
not build draw/gallivm/llvmpipe.
If you want to build some other component with LLVM but not
draw/gallivm/llvmpipe, then add a new HAVE_LLVM_FOR_FOOBAR define and
use it where you need it.
And honestly, I think people should reconsider enabling building parts
with Mesa with LLVM and others without it. It sounds an awful idea that
will cause nothing more than grief. But that's not for me to decide.
Jose
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
