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

Wed Mar 29 22:27:58 UTC 2017

On 28/03/17 22:37, Dylan Baker wrote:
> Quoting Jose Fonseca (2017-03-28 13:45:57)
>> 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

I found 
https://github.com/mesonbuild/meson/wiki/Shipping-prebuilt-binaries-as-wraps 
which describes how to this precisely this.

>
> That might be a viable option too. I'm still going to have a go at freeglut, it
> should be pretty easy to do, and getting it in the wrapdb would probably be
> useful.
>
> Dylan
>

Sure.

Jose