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

Tue Mar 28 20:32:43 UTC 2017

Quoting Jose Fonseca (2017-03-28 09:19:48)
> On 28/03/17 00:12, Dylan Baker wrote:
> > 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
> 
> Thanks.
> 
> GLEW is not the only one case though.  There's also FREEGLUT.  So we 
> can't really avoid the problem of external windows binaries/subprojects.
> 
> So I've been thinking, and I suspect is better if first get things 
> working with binary GLEW / FREGLUT projects, then try the glew -> 
> libepoxy in a 2nd step, so there's less to take in to merge meson into 
> master.
> 
> > 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
> 
> I'm pretty sure the problem with MinGW glu is the lack of windows.h.  We 
> need to do the same as CMakeLists.txt snippet quoted below.
> 
> I'm running out of time today, but I'll look into porting this over to 
> meson tomorrow if you don't beat me to it.
> 
> Jose
> 
> 
> 
> if (WIN32)
>          # Nobody likes to include windows.h:
>          # - Microsoft's GL/gl.h header depends on windows.h but doesn't 
> include it;
>          # - GLEW temporarily defines the necessary defines but 
> undefines them later
>          # - certain GLUT distributions don't include it;
>          # - most of our programs are meant to be portable so don't 
> include it.
>          #
>          # We could try to replicate the windows.h definitions required by
>          # GL/gl.h, but the build time savings don't compensate the constant
>          # headaches that brings, so instead we force windows.h to be 
> included
>          # on every file.
>          if (MSVC)
>                  add_definitions (-FIwindows.h)
>          else (MSVC)
>                  add_definitions (--include windows.h)
>          endif (MSVC)
> 
>          # Don't define min/max macros
>          add_definitions (-DNOMINMAX)
> 
>          # MSVC & MinGW only define & use APIENTRY
>          add_definitions (-DGLAPIENTRY=__stdcall)
> 
>          link_libraries (winmm)
> endif (WIN32)
> 

Okay, I got things compiling and sorta working with mingw (tested with wine,
so...) and libepoxy. You might be right that the epoxy work is something that we
should do separately, I may try to write a freeglut wrap, it looks a bit more
straight forward than glew.

Also, epoxy merged fixes upstream to fix being built as a wrap, so I've added a
wrap file for it.

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/20170328/e8e5280a/attachment.sig>