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