[Mesa-dev] Lets talk about autotools

[Eric Engestrom]

On Tuesday, 2018-09-18 13:43:25 -0700, Dylan Baker wrote:
> 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.

There is :)
$ meson --internal regenerate

> 
> Dylan



> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev