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

[Jose Fonseca]

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