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

Tue Mar 28 20:45:57 UTC 2017

On 28/03/17 21:32, Dylan Baker wrote:
> 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.

I've been pondering on this further, and I wonder if a good compromise a 
subproject for glew/freeglut, that instead of building those said 
dependencies, would simply fetch and unpack the files in a build subdir, 
and would setup the meson dependency object (ie, path to includes, path 
to libs.)

For example, the freeglut project would download the windows binaries, 
32 or 64 bits based on the target build, perhaps checksum them, unpack, 
etc.

This would have the feel of a wrap, without the headaches of actually 
porting the dependency to meson.  (Nothing prevent us of doing that in 
the long term thought.  But it would simplify things in the short term.)

We could host the binaries somewhere in freedesktop.org too for 
protecting against broken urls etc.

Jose