[Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

Dylan Baker dylan at pnwbakers.com
Mon Mar 27 23:12:14 UTC 2017


Quoting Jose Fonseca (2017-03-27 09:58:59)
> On 27/03/17 17:42, Dylan Baker wrote:
> > Quoting Jose Fonseca (2017-03-27 09:31:04)
> >> On 27/03/17 17:24, Dylan Baker wrote:
> >>> Quoting Jose Fonseca (2017-03-26 14:53:50)
> >>>> I've pushed the branch to mesa/demos, so we can all collaborate without
> >>>> wasting time crossporting patches between private branches.
> >>>>
> >>>>    https://cgit.freedesktop.org/mesa/demos/commit/?h=meson
> >>>>
> >>>> Unfortunately, I couldn't actually go very far until I hit a wall, as
> >>>> you can see in the last commit message.
> >>>>
> >>>>
> >>>> The issue is that Windows has no standard paths for dependencies
> >>>> includes/libraries (like /usr/include or /usr/lib), nor standard tool
> >>>> for dependencies (no pkgconfig).  But it seems that Meson presumes any
> >>>> unknown dependency can be resolved with pkgconfig.
> >>>>
> >>>>
> >>>> The question is: how do I tell Meson where the GLEW headers/library for
> >>>> MinGW are supposed to be found?
> >>>>
> >>>>
> >>>> I know one solution might be Meson Wraps.  Is that the only way?
> >>>>
> >>>>
> >>>> CMake makes it very easy to do it (via Cache files as explained in my
> >>>> commit message.)  Is there a way to achieve the same, perhaps via
> >>>> cross_file properties or something like that?
> >>>>
> >>>>
> >>>> Jose
> >>>
> >>> I think there are two ways you could solve this:
> >>>
> >>> Wraps are probably the most generically correct method; what I mean by that is
> >>> that a proper wrap would solve the problem for everyone, on every operating
> >>> system, forever.
> >>
> >> Yeah, that sounded a good solution, particularly for windows where's so
> >> much easier to just build the dependencies as a subproject rather than
> >> fetch dependencies from somewhere, since MSVC RT versions have to match
> >> and so.
> >>
> >>  > That said, I took a look at GLEW and it doesn't look like a
> >>> straightforward project to port to meson, since it uses a huge pile of gnu
> >>> makefiles for compilation, without any autoconf/cmake/etc. I still might take a
> >>> swing at it since I want to know how hard it would be to write a wrap file for
> >>> something like GLEW (and it would probably be a pretty useful project to wrap)
> >>> where a meson build system is likely never going to go upstream.
> >>
> >> BTW, regarding GLEW, some time ago I actually prototyped using GLAD
> >> instead of GLEW for mesademos:
> >>
> >>    https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=glad
> >>
> >> I find GLAD much nicer that GLEW: it's easier to build, it uses upstream
> >> XML files, it supports EGL, and it's easy to bundle.
> >>
> >> Maybe we could migrate mesademos to GLAD as part of this work instead of
> >> trying to get glew "mesonfied".
> >>
> >>> The other option I think you can use use is cross properties[1], which I believe
> >>> is the closest thing meson has to cmake's cache files.
> >>>
> >>> I've pushed a couple of commits, the last one implements the cross properties
> >>> idea, which gets the build farther, but then it can't find the glut headers,
> >>> and I don't understand why, since "cc.has_header('GL/glut')" returns true. I
> >>> still think that wraps are a better plan, but I'll have to spend some time today
> >>> working on a glew wrap.
> >>>
> >>> [1] https://github.com/mesonbuild/meson/wiki/Cross-compilation (at the bottom
> >>> under the heading "Custom Data")
> >>
> >> I'm running out of time today, but I'll try to take a look tomorrow.
> >>
> >> Jose
> >>
> >
> > I'd had a similar thought, but thought of libpeoxy? It supports the platforms we
> > want, and already has a meson build system that works for windows.
> 
> I have no experience with libepoxy.  I know GLAD is really easy to 
> understand, use and integrate.  It's completly agnostic to toolkits like 
> GLUT/GLFW/etc doesn't try to alias equivalent entrypoints, or anything 
> smart like libepoxy.
> 
> In particular I don't fully understand libepoxy behavior regarding 
> wglMakeCurrent is, and whether that will create problems with GLUT, 
> since GLUT will call wglMakeCurrent..
> 
> 
> Jose

Okay, I have libepoxy working for windows. I also got libepoxy working as a
subproject, but it took a bit of hacking on their build system (there's
some things they're doing that make them non-subproject safe, I'll send patches
and work that out with them.

https://github.com/dcbaker/libepoxy.git fix-suproject

Clone that repo into $mesa-demos-root/subprojects and things should just work,
or mostly work. I got epoxy compiling, but ran into some issues in the mingw glu
header.

Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170327/3004c0fb/attachment.sig>


More information about the mesa-dev mailing list