Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 652762 - media-libs/mesa-9999: meson conversion
Summary: media-libs/mesa-9999: meson conversion
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 616398 652664
  Show dependency tree
 
Reported: 2018-04-07 20:26 UTC by hanetzer
Modified: 2018-08-22 16:17 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build failure (file_652762.txt,4.57 KB, text/plain)
2018-06-02 03:02 UTC, hanetzer
Details
backward_platforms.patch (backward_platforms.patch,475 bytes, patch)
2018-06-03 18:46 UTC, cyrillic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description hanetzer 2018-04-07 20:26:32 UTC
Jello. At mattst88's prompting I have begun work on converting the mesa
live ebuild to make use of meson, and my current work can be seen here[1].

There are a few kinks to work out, but it does work with a few caveats.

abi_x86_32 builds on amd64 does not work because the x86_64 llvm-config 
is used instead of the i686 one, resulting in trying to link against
the wrong llvm libraries. This can be solved either in gentoo itself,
by making meson.eclass generate and use a cross file in this situation,
or by upstream meson allowing pointing to llvm-config via LLVM_CONFIG in
a manner similar to how autotools allows for it, and how they respect
PKG_CONFIG. I have filed a bug[2] with upstream about this, no action as
of yet.


1: https://github.com/hanetzer/gentoo/tree/mesa-meson/media-libs/mesa
2: https://github.com/mesonbuild/meson/issues/3327
Comment 1 Matt Turner gentoo-dev 2018-05-09 21:18:44 UTC
Marking this as a blocker of two bugs that are due to autotools/libtool.
Comment 2 cyrillic 2018-05-12 00:56:47 UTC
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.
Comment 3 hanetzer 2018-05-12 06:15:03 UTC
(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.
Comment 4 Mike Gilbert gentoo-dev 2018-05-29 14:51:56 UTC
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
Comment 5 Mike Gilbert gentoo-dev 2018-05-29 15:20:19 UTC
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.
Comment 6 hanetzer 2018-05-29 16:18:37 UTC
(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.
Comment 7 hanetzer 2018-05-29 16:26:18 UTC
Pushed, please feel free to test and comment.
Comment 8 Mike Gilbert gentoo-dev 2018-05-29 16:57:52 UTC
Try adding IUSE="test" and "-Dbuild-tests=$(usex test true false)" to emesonargs.

https://github.com/mesa3d/mesa/blob/master/meson_options.txt#L255
Comment 9 Mike Gilbert gentoo-dev 2018-05-29 16:59:31 UTC
I also suggest adding RESTRICT="!test? ( test )" to auto-disable testing in a PMS-compliant way.
Comment 10 hanetzer 2018-05-30 00:10:02 UTC
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.
Comment 11 Matt Turner gentoo-dev 2018-05-30 00:18:27 UTC
(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.
Comment 12 hanetzer 2018-06-02 03:02:41 UTC
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.
Comment 13 Mike Gilbert gentoo-dev 2018-06-02 13:30:06 UTC
(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
Comment 14 hanetzer 2018-06-02 18:13:56 UTC
(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.
Comment 15 cyrillic 2018-06-02 21:36:50 UTC
(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 ...
Comment 16 Mike Gilbert gentoo-dev 2018-06-02 23:50:53 UTC
(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.
Comment 17 Matt Turner gentoo-dev 2018-06-03 00:27:19 UTC
(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.
Comment 18 Mike Gilbert gentoo-dev 2018-06-03 00:58:41 UTC
(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')
Comment 19 cyrillic 2018-06-03 18:46:04 UTC
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.
Comment 20 Matt Turner gentoo-dev 2018-06-05 18:40:58 UTC
(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
Comment 21 Larry the Git Cow gentoo-dev 2018-06-08 04:16:43 UTC
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(-)
Comment 22 cyrillic 2018-07-04 22:17:55 UTC
(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 ...