On 19 January 2017 at 19:26, Tobias Droste <tdro...@gmx.de> wrote:
> Am Mittwoch, 18. Januar 2017, 18:45:04 CET schrieb Emil Velikov:
>> On 18 January 2017 at 18:12, Jose Fonseca <jfons...@vmware.com> 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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
