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.
Cheers,
Kai
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
