Jose Fonseca <jfons...@vmware.com> writes: > 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..
libepoxy does "keep a vtable of resolved functions per context, wrap wglMakeCurrent to trigger re-resolve when we change contexts". For handling things like glut's wglMakeCurrent, there's a public epoxy_handle_external_wglMakeCurrent() function you can call. If you use glut and fail to call epoxy_handle_external_wglMakeCurrent(), you'll end up with resolution inside the global function pointers, which is going to be fine if you only ever have one context in glut. There's a note for "we should probably track the resolved functions per context rather than throwing out resolution on every MakeCurrent", but I don't actually know if anyone wants that.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
