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