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