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 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
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
