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

[Dylan Baker]

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 a port to libepoxy that works on linux, using it as a subproject is
turning out to be rather difficult, in part because of the way that the libepoxy
meson is written. I'm hoping to spend some more time on this tonight, but I'm
not sure I have time.

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/ebaf695a/attachment-0001.sig>