[Mesa-dev] Lets talk about autotools

[Dylan Baker]

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
-------------- 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/2dfcd940/attachment.sig>