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? JoseI 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 astraightforward 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. JoseI'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.. JoseOkay, 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-suprojectThanks. 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. DylanI'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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
