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 <jfons...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
