Quoting Kai Wasserbäch (2018-09-18 11:14:19)
> Dylan Baker wrote on 9/18/18 6:40 PM:
> > Quoting Kai Wasserbäch (2018-09-18 08:56:30)
> >> Dylan Baker wrote on 9/18/18 5:35 PM:
> >>> [...]
> >>>
> >>> This is something we've discussed upstream several times. I will freely
> >>> admit
> >>> that llvm-config is a huge pain in the ass to deal with for a ton of
> >>> reasons,
> >>> and since we don't use it at Intel
> >>
> >> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no
> >> longer
> >> the case?
> >
> > Our relationship with the KBL-G is complicated :)
>
> Well, there's also SWR from Intel, which also relies on LLVM...
>
> >>> it hasn't been on the top of my list of
> >>> things to do, and also because the solution upstream wants is very
> >>> non-trival to
> >>> implement. This has come up already and I am working on it right now.
> >>
> >> If upstream support is unreasonable, I'd like to see a similar solution to
> >> LLVM_CONFIG as it's in autotools today. It must be possible to
> >> mangle/override
> >> the meson variables right? (This might be totally ignorant, because I was
> >> able
> >> to avoid Meson so far and all other build systems I've worked with, have
> >> one or
> >> more options to set variables. Either by having an option in the build
> >> files or
> >> by passing some option into the configure step.)
> >
> > It really isn't, the only way we could really override this today is to
> > allow
> > you to pass a version requirement. One of the guiding ideas of meson is that
> > complicated logic like "how the hell do you make a tool as
> > broken-by-design-and-implementation as llvm-config work" should be part of
> > meson
> > itself and not in the local build-system. The downside of that is that
> > upstream
> > really wants you to think about how you handle things like overriding a
> > specific
> > binary like llvm-config because it has to live with that decision for a long
> > time.
>
> I'm for the hiding, but why not do it in an easy to change way like the
> "Find${FOO}.cmake" scripts? As long as you get certain variables populated
> downstream is happy and an occasional change can be managed, if it should
> become
> necessary. Having everything "in the core" sounds rather inflexible to me. Or
> I'm misunderstanding you. Anyway, this isn't really the topic here.
>
> >>> The other option you have it to set the $PATH variable, as long as the
> >>> llvm-config you want returns the highest version things will work as you
> >>> expect.
> >>
> >> This might do as a workaround, though I'm not too keen on extending $PATH.
> >> But
> >> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain
> >> that
> >> versions binaries, putting it first into the path could work.
> >
> > meson will cache the llvm-config values, so you should be able to just do
> > something like:
> >
> > PATH=/path/to/my/llvm meson build-with-my-llvm
>
> Ok. Where's the cache? In the build directory or is this something, that's
> kept
> globally and needs potential clearing? A quick search for this feature yielded
> <https://mesonbuild.com/Release-notes-for-0-38-0.html>. That makes it sound
> like
> it is global, which I would almost consider broken design. Or is it local but
> kept between multiple invocations of meson? That also sounds like a recipe for
> disaster, though it would be easier to deal with: just nuke the build
> directory.It's per build directory, and is kept on subsequent rebuilds. The idea is that if you need to reconfigure a build (say meson.build changes) when you do a `git pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes the rebuild faster. I don't think there is a cache-invalidation method, though that would be a nice feature to have. Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
