[Mesa-dev] Lets talk about autotools

[Dylan Baker]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180918/3b8a84c0/attachment.sig>