Quoting Jose Fonseca (2017-03-29 15:27:58) > 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? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 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 > > 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
That does look incredibly useful, especially for mesa. There are some dependencies that I have no interest in porting to meson (LLVM), I did get freeglut ported to meson (It was pretty easy), and tested it for mingw cross compiling. It's pushed upstream. Libepoxy also fixed their build upstream to work as a dependency, so I've added a wrap that just clones upstream using git, and we can migrate that to not git when they make another release, or we can package glew as a binary wrap, and deal with using a epoxy or glad or something later. Upstream is also following this thread and has opened this bug: https://github.com/mesonbuild/meson/issues/1524 So that may simplify some things even further. Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev