Quoting Kai Wasserbäch (2018-09-18 08:56:30)
> Dylan Baker wrote on 9/18/18 5:35 PM:
> > Quoting Kai Wasserbäch (2018-09-18 07:43:08)
> >> Hey,
> >> Dylan Baker wrote on 9/17/18 6:44 PM:
> >>> I feel like for !windows meson is in good enough shape at this point that
> >>> we
> >>> can start having the discussion about deleting the autotools build. So,
> >>> is there
> >>> anything left that autotools can do that meson cannot (that we actually
> >>> want to
> >>> implement)? And, what is a reasonable time-table to remove the autotools
> >>> build?
> >>> I think we could reasonably remove it as soon as 18.3 if others felt
> >>> confident
> >>> that it would work for them.
> >>
> >> How do I set a specific llvm-config name to look for? I have build
> >> environments
> >> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far
> >> I
> >> could convince each build system with LLVM_CONFIG or similar means to
> >> choose a
> >> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
> >>
> >> Eric pointed me to an ugly hack on IRC, which involves symlinking the
> >> particular
> >> llvm-config-${VERSION} to llvm-config in $PATH
> >> (<https://gitlab.freedesktop.org/mesa/mesa/commit/b5b912dfeebabafbaff176fe4205eb74607f709b>).
> >> But I think this should be fixed properly before making meson mandatory.
> >> Other
> >> modern build systems like CMake react to something like -DLLVM_DIR during
> >> configure (see
> >> <https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project>) and
> >> Mesa's
> >> stable build systems use LLVM_CONFIG, if set.
> >>
> >> Cheers,
> >> Kai
> >
> > 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 :)
> > 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.
> > 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
Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
