[Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Dylan Baker
dylan at pnwbakers.com
Thu Mar 30 18:52:29 UTC 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170330/2f17dad3/attachment.sig>
More information about the mesa-dev
mailing list