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. Also, epoxy merged fixes upstream to fix being built as a wrap, so I've added a wrap file for it. Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
