Summary: | media-libs/mesa-9999: meson conversion | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | hanetzer |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | floppym, tsmksubc |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 616398, 652664 | ||
Attachments: |
build failure
backward_platforms.patch |
Description
hanetzer
2018-04-07 20:26:32 UTC
Marking this as a blocker of two bugs that are due to autotools/libtool. I tried your ebuild, and had a little trouble with src_configure() : The autotools version was okay with building both gallium and classic versions of the drivers, but the meson version wanted me to choose one or the other. I also added this to src_install() : # These files are now provided by wayland-9999 rm "${ED}/usr/$(get_libdir)/libwayland-egl.so" || die rm "${ED}/usr/$(get_libdir)/libwayland-egl.so.1" || die rm "${ED}/usr/$(get_libdir)/libwayland-egl.so.1.0.0" || die rm "${ED}/usr/$(get_libdir)/pkgconfig/wayland-egl.pc" || die It should probably depend on which version of dev-libs/wayland is installed. (In reply to cyrillic from comment #2) > I tried your ebuild, and had a little trouble with src_configure() : > The autotools version was okay with building both gallium and classic > versions of the drivers, but the meson version wanted me to choose one or > the other. > > I also added this to src_install() : > # These files are now provided by wayland-9999 > rm "${ED}/usr/$(get_libdir)/libwayland-egl.so" || die > rm "${ED}/usr/$(get_libdir)/libwayland-egl.so.1" || die > rm "${ED}/usr/$(get_libdir)/libwayland-egl.so.1.0.0" || die > rm "${ED}/usr/$(get_libdir)/pkgconfig/wayland-egl.pc" || die > > It should probably depend on which version of dev-libs/wayland is installed. Yeah, its a limitation of the upstream mesa meson build, nothing we can do on our end aside from monkeypatching it a bit. Ah, I was not aware of those files being part of wayland, good on ya. Glad to have testers. I have updated meson.eclass to use a cross file for non-default ABIs. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c804e6ec479119cd4f0d5ae0e0657c8384bba578 I also added the llvm-config binary. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=360ee05e307e79959af7fc5771c4a080fde4f256 Regarding your meson-9999 ebuild: You need to define a multilib_src_compile function that calls meson_src_compile. You should also define a multilib_src_test function to call meson_src_test. (In reply to Mike Gilbert from comment #5) > Regarding your meson-9999 ebuild: > > You need to define a multilib_src_compile function that calls > meson_src_compile. > > You should also define a multilib_src_test function to call meson_src_test. multilib_src_test() { # if use llvm; then # local llvm_tests='lp_test_arit lp_test_arit lp_test_blend lp_test_blend lp_test_conv lp_test_conv lp_test_forma t lp_test_format lp_test_printf lp_test_printf' # pushd src/gallium/drivers/llvmpipe >/dev/null || die # emake ${llvm_tests} # pax-mark m ${llvm_tests} # popd >/dev/null || die # fi meson_src_test } With this change I get >>> Test phase: media-libs/mesa-9999 * abi_x86_32.x86: running multilib-minimal_abi_src_test ninja -v -j16 -l0 -C /tmp/portage/media-libs/mesa-9999/work/mesa-9999-abi_x86_32.x86 test ninja: Entering directory `/tmp/portage/media-libs/mesa-9999/work/mesa-9999-abi_x86_32.x86' [1/30] /tmp/portage/media-libs/mesa-9999/temp/python2.7/bin/python2 ../mesa-9999/bin/git_sha1_gen.py --output src/git_s ha1.h [1/2] /usr/bin/python3.5 -u /usr/lib/python-exec/python3.5/meson test --no-rebuild --print-errorlogs No tests defined. * abi_x86_64.amd64: running multilib-minimal_abi_src_test ninja -v -j16 -l0 -C /tmp/portage/media-libs/mesa-9999/work/mesa-9999-abi_x86_64.amd64 test ninja: Entering directory `/tmp/portage/media-libs/mesa-9999/work/mesa-9999-abi_x86_64.amd64' [1/30] /tmp/portage/media-libs/mesa-9999/temp/python2.7/bin/python2 ../mesa-9999/bin/git_sha1_gen.py --output src/git_s ha1.h [1/2] /usr/bin/python3.5 -u /usr/lib/python-exec/python3.5/meson test --no-rebuild --print-errorlogs No tests defined. I think I'm going to have to do some more investigation on this. Adding multilib_src_compile/meson_src_compile builds and installs; I'll be adding the rm'ing of the wayland stuff to src_install as well. Pushed, please feel free to test and comment. Try adding IUSE="test" and "-Dbuild-tests=$(usex test true false)" to emesonargs. https://github.com/mesa3d/mesa/blob/master/meson_options.txt#L255 I also suggest adding RESTRICT="!test? ( test )" to auto-disable testing in a PMS-compliant way. Ah, that seems to have done it; all appears to be working now, excluding the upstream inability to do both dri and gallium swrast at the same time. (In reply to hanetzer from comment #10) > Ah, that seems to have done it; all appears to be working now, > excluding the upstream inability to do both dri and gallium > swrast at the same time. I don't think we should care about that. I've started the ball rolling on killing eselect-mesa. I'd say if gallium is enabled give the user the gallium version, and if not, give them the other. I sent Dylan (the guy doing most of the Meson work in Mesa) an email with a list of things that you noted were missing: """ - No analog for --with-clang-libdir= - No analog for --enable-glx-read-only-text - No analog for --enable-glx-tls (I think this is fine) - No analog for --enable-llvm-shared-libs I also noticed we're installing libGLESv1_CM.so.1.0.0 instead of libGLESv1_CM.so.1.1.0. I remember us talking about this. I suspect it's fine. """ I'm not sure if --with-clang-libdir= is necessary, and I don't think --enable-glx-tls is (it's on by default now). I think we do want to add --enable-glx-read-only-text to Meson. Maybe you'd like to send a patch upstream for that one? I don't know what to do about --enable-llvm-shared-libs. mgorny is militantly in favor of shipping LLVM as a collection of small shared libraries against the advice of... everyone upstream, as far as I can tell. Created attachment 534438 [details]
build failure
Hrm. Unsure what the actual issue is here; you can plainly see
-Dplatforms=x11,surfaceless,wayland,drm specified on the meson
invocation.
(In reply to hanetzer from comment #12) It's a bug in the meson.build file, introduced by this commit. https://github.com/mesa3d/mesa/commit/0ed6a87a106b6e2266e01c5d7e31344229833c8d (In reply to Mike Gilbert from comment #13) > (In reply to hanetzer from comment #12) > > It's a bug in the meson.build file, introduced by this commit. > > https://github.com/mesa3d/mesa/commit/ > 0ed6a87a106b6e2266e01c5d7e31344229833c8d Ah, good to know. Really spooks ya when something that did use to work ceases to without any outside intervention from yourself. (In reply to Mike Gilbert from comment #13) > (In reply to hanetzer from comment #12) > > It's a bug in the meson.build file, introduced by this commit. Not only did the platforms get messed around with, but most of the other options did too. I think this is on purpose ... (In reply to cyrillic from comment #15) The problematic code is this: > elif with_platforms > error('No platforms specified, consider -Dplatforms=drm,x11 at least') That logic makes absolutely no sense. (In reply to Mike Gilbert from comment #16) > (In reply to cyrillic from comment #15) > > The problematic code is this: > > > elif with_platforms > > error('No platforms specified, consider -Dplatforms=drm,x11 at least') > > That logic makes absolutely no sense. Why not? I can relay the problem to the right people, if I understood it. (In reply to Matt Turner from comment #17) > if _platforms.length() != 0 and _platforms != [''] > with_platforms = true > egl_native_platform = _platforms[0] > endif In English: with_platforms is set to true if any platform is enabled. > elif with_platforms > error('No platforms specified, consider -Dplatforms=drm,x11 at least') The error message states: "No platforms specified, consider -Dplatforms=drm,x11 at least". This is an obvious contradiction. The author probably meant to write this: > elif not with_platforms > error('No platforms specified, consider -Dplatforms=drm,x11 at least') Created attachment 534684 [details, diff] backward_platforms.patch (In reply to Mike Gilbert from comment #18) > (In reply to Matt Turner from comment #17) > > The author probably meant to write this: > > > elif not with_platforms > > error('No platforms specified, consider -Dplatforms=drm,x11 at least') Yup, that fixes it for me. (In reply to Mike Gilbert from comment #18) > (In reply to Matt Turner from comment #17) > > > if _platforms.length() != 0 and _platforms != [''] > > with_platforms = true > > egl_native_platform = _platforms[0] > > endif > > In English: with_platforms is set to true if any platform is enabled. > > > elif with_platforms > > error('No platforms specified, consider -Dplatforms=drm,x11 at least') > > The error message states: "No platforms specified, consider > -Dplatforms=drm,x11 at least". This is an obvious contradiction. > > The author probably meant to write this: > > > elif not with_platforms > > error('No platforms specified, consider -Dplatforms=drm,x11 at least') Thanks, this is now fixed upstream by https://cgit.freedesktop.org/mesa/mesa/commit/?id=7c4423cce98f95c3ab7349b3f7abc4a558cb6c48 The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec1ca5afa84af6a0c28a5b38322699d86a798260 commit ec1ca5afa84af6a0c28a5b38322699d86a798260 Author: Marty E. Plummer <hanetzer@startmail.com> AuthorDate: 2018-03-24 04:18:36 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2018-06-08 04:16:32 +0000 media-libs/mesa: Convert build to meson With various changes by mattst88: - Add lm_sensors to IUSE, lest it be automagic - Depend on bison and flex unconditionally - Fix libGLESv1_CM in QA_WX_LOAD (Meson installs under a different name) Closes: https://bugs.gentoo.org/652762 media-libs/mesa/mesa-9999.ebuild | 171 +++++++++++++++++---------------------- 1 file changed, 73 insertions(+), 98 deletions(-) (In reply to hanetzer from comment #10) > all appears to be working now, > excluding the upstream inability to do both dri and gallium > swrast at the same time. Actually, this is not an upstream limitation. I found that I could build drivers for multiple video cards like intel(classic), radeon(gallium), nouveau(both) without getting conflicts if I pass these configure options : -Ddri-drivers=auto -Dgallium-drivers=auto Of course, this is not compatible with the way the official ebuild does things ... |