Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Jose Fonseca (2017-09-22 11:58:17) > On 22/09/17 19:38, Dylan Baker wrote: > > Quoting Jose Fonseca (2017-09-22 11:10:34) > >> On 22/09/17 18:47, Nirbheek Chauhan wrote: > >>> On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca > >>> wrote: > cmake provides a generic mechanism to set any variable, either from a > command line -DFOO=boo, or via cache files. But meson didn't provide > such > standard mechanism AFAICT. > > >>> > >>> In Meson you must define an option to pass data to the build file. > >>> This cannot change since it would go against the basic design > >>> principles of Meson. > >>> > Furthermore, this needs to work both with pkg-config on Linux, and > non-pkgconfig on Windows. We don't want to have one set of meson files > that > use pkconfig subprojects for Linux, and other that use something else for > Windows. > > >>> > >>> FWIW, a lot of projects use pkg-config on Windows and macOS too since > >>> pkg-config is a cross-platform standard. > >>> > >>> I do understand that it can be a hassle ensuring the existence of > >>> pkg-config.exe and convincing some projects that they should add > >>> pkg-config files. Perhaps we can improve that by installing a > >>> standalone pkg-config.exe with our Windows MSI installers. > >> > >> I think it's a mistake for Meson depend on pkg-config.exe on Windows. > >> > >> Is completely unfit for purpose IMHO. cygwin/msys/WSL all might ship > >> their pkg-config, and who knows what they'll find. > >> > >> Plus each project will have specific needs. Maybe I'm using MSVC 2017. > >> Maybe I'm using MSVC 2012. I'll need different static libraries for > >> those. There's no such thing as a centralized repository for > >> dependencies on Windows. There simply can't be. At least outside POSIX > >> ports like cygwin/msys/etc > >> > >> An while building all dependencies from source would solve that, that's > >> also unpractical. Not only becuase it would take time to convert them > >> to meson, but also because often source is not available. > >> > >>> We also have Windows-specific code in our Sdl2, Boost, Qt, and other > >>> dependency search classes which is our preferred mechanism to detect > >>> dependencies that are distributed via installers and can be found in > >>> 'standard' locations. > >> > >> Right. What Meson lacks is a simple mechanism to generalize that for > >> any binary package without pkg-config. > >> > >>> > > for you, we'd love to talk about how we can improve things. For > > instance, there were these proposals: > > https://github.com/mesonbuild/meson/issues/1525 and > > https://github.com/mesonbuild/meson/issues/1524, but we didn't get any > > feedback on whether they would actually be useful in real-world usage. > > > I think those were added precisely as a consequence of my discussions > with > Dylan on porting mesademos. > > meson subprojects assume too much: they either expect pkg-config, or they > expect the subprojects to have source and meson files. > > >>> > >>> Meson does not require pkg-config to find dependencies, but yes we do > >>> recommend it because it makes the job very easy. > >>> > >>> Meson subprojects exist precisely so you can avoid looking outside the > >>> source tree for dependencies, so you should not need pkg-config. For > >>> instance, you can also create a subproject that exports dependency > >>> objects for pre-built binaries just fine. We should publish an example > >>> so people know how to do it. > >>> > > Meson is (IMO) unusual in the build systems world in that it's not a > > static unchangeable upstream (ala cmake/autotools/scons), but is a > > FOSS project that you can interact with, so please talk to us. :) > > > Well, that's a good and a bad thing. It's certainly great that you're > open > for discussion. But I'm afraid the fact that so much interaction is > necessary means meson still has some ways to go. Honestly, besides > filing a > couple of bugs, I never felt the need to interact with CMake/SCons > development community and driver their direction. It pretty much did > what I > needed. I don't want to build a build system myself. And I fear living > on > the bleeding edge myself. > > >>> > >>> In my experience, I really wished that cmake/scons upstream cared a > >>> bit more about my use-cases and I didn't have to hack everything I > >>> wanted into my build files with macros. ;) > >>> > >>> I've found cmake projects to be more fragile and harder to understand > >>> than even Autotools, but perhaps I'm just looking at badly-written > >>> build files. This is one of the reasons why Meson restricts what you > >>> can do in a build file — to make it harder for people to write bad > >>> ones! > >>> > I'll be honest, I'm happy to evaluate meson as potential replacement > b
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 22/09/17 19:38, Dylan Baker wrote: Quoting Jose Fonseca (2017-09-22 11:10:34) On 22/09/17 18:47, Nirbheek Chauhan wrote: On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca wrote: cmake provides a generic mechanism to set any variable, either from a command line -DFOO=boo, or via cache files. But meson didn't provide such standard mechanism AFAICT. In Meson you must define an option to pass data to the build file. This cannot change since it would go against the basic design principles of Meson. Furthermore, this needs to work both with pkg-config on Linux, and non-pkgconfig on Windows. We don't want to have one set of meson files that use pkconfig subprojects for Linux, and other that use something else for Windows. FWIW, a lot of projects use pkg-config on Windows and macOS too since pkg-config is a cross-platform standard. I do understand that it can be a hassle ensuring the existence of pkg-config.exe and convincing some projects that they should add pkg-config files. Perhaps we can improve that by installing a standalone pkg-config.exe with our Windows MSI installers. I think it's a mistake for Meson depend on pkg-config.exe on Windows. Is completely unfit for purpose IMHO. cygwin/msys/WSL all might ship their pkg-config, and who knows what they'll find. Plus each project will have specific needs. Maybe I'm using MSVC 2017. Maybe I'm using MSVC 2012. I'll need different static libraries for those. There's no such thing as a centralized repository for dependencies on Windows. There simply can't be. At least outside POSIX ports like cygwin/msys/etc An while building all dependencies from source would solve that, that's also unpractical. Not only becuase it would take time to convert them to meson, but also because often source is not available. We also have Windows-specific code in our Sdl2, Boost, Qt, and other dependency search classes which is our preferred mechanism to detect dependencies that are distributed via installers and can be found in 'standard' locations. Right. What Meson lacks is a simple mechanism to generalize that for any binary package without pkg-config. for you, we'd love to talk about how we can improve things. For instance, there were these proposals: https://github.com/mesonbuild/meson/issues/1525 and https://github.com/mesonbuild/meson/issues/1524, but we didn't get any feedback on whether they would actually be useful in real-world usage. I think those were added precisely as a consequence of my discussions with Dylan on porting mesademos. meson subprojects assume too much: they either expect pkg-config, or they expect the subprojects to have source and meson files. Meson does not require pkg-config to find dependencies, but yes we do recommend it because it makes the job very easy. Meson subprojects exist precisely so you can avoid looking outside the source tree for dependencies, so you should not need pkg-config. For instance, you can also create a subproject that exports dependency objects for pre-built binaries just fine. We should publish an example so people know how to do it. Meson is (IMO) unusual in the build systems world in that it's not a static unchangeable upstream (ala cmake/autotools/scons), but is a FOSS project that you can interact with, so please talk to us. :) Well, that's a good and a bad thing. It's certainly great that you're open for discussion. But I'm afraid the fact that so much interaction is necessary means meson still has some ways to go. Honestly, besides filing a couple of bugs, I never felt the need to interact with CMake/SCons development community and driver their direction. It pretty much did what I needed. I don't want to build a build system myself. And I fear living on the bleeding edge myself. In my experience, I really wished that cmake/scons upstream cared a bit more about my use-cases and I didn't have to hack everything I wanted into my build files with macros. ;) I've found cmake projects to be more fragile and harder to understand than even Autotools, but perhaps I'm just looking at badly-written build files. This is one of the reasons why Meson restricts what you can do in a build file — to make it harder for people to write bad ones! I'll be honest, I'm happy to evaluate meson as potential replacement build system for SCons. But to put time in raising meson up to the point where it can be a replacement for SCons is beyond what I'm willing to do. That's fair, but it seems that there are Mesa developers who are interested in doing this, and I do enjoy working with them. The code we get is always high quality. :-) It seems Meson needs a bit more time to mature and grow a more diverse user community. It seems a bit lopsided at the moment. I see no other explanation for us to hit issues with meson that nobody else hit before. Based mostly on contributions, people are using Meson on all Linux distros, all BSDs, Windows, macOS, Solaris, and even Haiku. Talking spe
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Jose Fonseca (2017-09-22 11:10:34) > On 22/09/17 18:47, Nirbheek Chauhan wrote: > > On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca wrote: > >> cmake provides a generic mechanism to set any variable, either from a > >> command line -DFOO=boo, or via cache files. But meson didn't provide such > >> standard mechanism AFAICT. > >> > > > > In Meson you must define an option to pass data to the build file. > > This cannot change since it would go against the basic design > > principles of Meson. > > > >> Furthermore, this needs to work both with pkg-config on Linux, and > >> non-pkgconfig on Windows. We don't want to have one set of meson files > >> that > >> use pkconfig subprojects for Linux, and other that use something else for > >> Windows. > >> > > > > FWIW, a lot of projects use pkg-config on Windows and macOS too since > > pkg-config is a cross-platform standard. > > > > I do understand that it can be a hassle ensuring the existence of > > pkg-config.exe and convincing some projects that they should add > > pkg-config files. Perhaps we can improve that by installing a > > standalone pkg-config.exe with our Windows MSI installers. > > I think it's a mistake for Meson depend on pkg-config.exe on Windows. > > Is completely unfit for purpose IMHO. cygwin/msys/WSL all might ship > their pkg-config, and who knows what they'll find. > > Plus each project will have specific needs. Maybe I'm using MSVC 2017. > Maybe I'm using MSVC 2012. I'll need different static libraries for > those. There's no such thing as a centralized repository for > dependencies on Windows. There simply can't be. At least outside POSIX > ports like cygwin/msys/etc > > An while building all dependencies from source would solve that, that's > also unpractical. Not only becuase it would take time to convert them > to meson, but also because often source is not available. > > > We also have Windows-specific code in our Sdl2, Boost, Qt, and other > > dependency search classes which is our preferred mechanism to detect > > dependencies that are distributed via installers and can be found in > > 'standard' locations. > > Right. What Meson lacks is a simple mechanism to generalize that for > any binary package without pkg-config. > > > > >>> for you, we'd love to talk about how we can improve things. For > >>> instance, there were these proposals: > >>> https://github.com/mesonbuild/meson/issues/1525 and > >>> https://github.com/mesonbuild/meson/issues/1524, but we didn't get any > >>> feedback on whether they would actually be useful in real-world usage. > >> > >> > >> I think those were added precisely as a consequence of my discussions with > >> Dylan on porting mesademos. > >> > >> meson subprojects assume too much: they either expect pkg-config, or they > >> expect the subprojects to have source and meson files. > >> > > > > Meson does not require pkg-config to find dependencies, but yes we do > > recommend it because it makes the job very easy. > > > > Meson subprojects exist precisely so you can avoid looking outside the > > source tree for dependencies, so you should not need pkg-config. For > > instance, you can also create a subproject that exports dependency > > objects for pre-built binaries just fine. We should publish an example > > so people know how to do it. > > > >>> Meson is (IMO) unusual in the build systems world in that it's not a > >>> static unchangeable upstream (ala cmake/autotools/scons), but is a > >>> FOSS project that you can interact with, so please talk to us. :) > >> > >> > >> Well, that's a good and a bad thing. It's certainly great that you're open > >> for discussion. But I'm afraid the fact that so much interaction is > >> necessary means meson still has some ways to go. Honestly, besides filing > >> a > >> couple of bugs, I never felt the need to interact with CMake/SCons > >> development community and driver their direction. It pretty much did what > >> I > >> needed. I don't want to build a build system myself. And I fear living on > >> the bleeding edge myself. > >> > > > > In my experience, I really wished that cmake/scons upstream cared a > > bit more about my use-cases and I didn't have to hack everything I > > wanted into my build files with macros. ;) > > > > I've found cmake projects to be more fragile and harder to understand > > than even Autotools, but perhaps I'm just looking at badly-written > > build files. This is one of the reasons why Meson restricts what you > > can do in a build file — to make it harder for people to write bad > > ones! > > > >> I'll be honest, I'm happy to evaluate meson as potential replacement build > >> system for SCons. But to put time in raising meson up to the point where > >> it > >> can be a replacement for SCons is beyond what I'm willing to do. > >> > > > > That's fair, but it seems that there are Mesa developers who are > > interested in doing this, and I do enjoy working with them. The code > > we get is
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 22/09/17 18:47, Nirbheek Chauhan wrote: On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca wrote: cmake provides a generic mechanism to set any variable, either from a command line -DFOO=boo, or via cache files. But meson didn't provide such standard mechanism AFAICT. In Meson you must define an option to pass data to the build file. This cannot change since it would go against the basic design principles of Meson. Furthermore, this needs to work both with pkg-config on Linux, and non-pkgconfig on Windows. We don't want to have one set of meson files that use pkconfig subprojects for Linux, and other that use something else for Windows. FWIW, a lot of projects use pkg-config on Windows and macOS too since pkg-config is a cross-platform standard. I do understand that it can be a hassle ensuring the existence of pkg-config.exe and convincing some projects that they should add pkg-config files. Perhaps we can improve that by installing a standalone pkg-config.exe with our Windows MSI installers. I think it's a mistake for Meson depend on pkg-config.exe on Windows. Is completely unfit for purpose IMHO. cygwin/msys/WSL all might ship their pkg-config, and who knows what they'll find. Plus each project will have specific needs. Maybe I'm using MSVC 2017. Maybe I'm using MSVC 2012. I'll need different static libraries for those. There's no such thing as a centralized repository for dependencies on Windows. There simply can't be. At least outside POSIX ports like cygwin/msys/etc An while building all dependencies from source would solve that, that's also unpractical. Not only becuase it would take time to convert them to meson, but also because often source is not available. We also have Windows-specific code in our Sdl2, Boost, Qt, and other dependency search classes which is our preferred mechanism to detect dependencies that are distributed via installers and can be found in 'standard' locations. Right. What Meson lacks is a simple mechanism to generalize that for any binary package without pkg-config. for you, we'd love to talk about how we can improve things. For instance, there were these proposals: https://github.com/mesonbuild/meson/issues/1525 and https://github.com/mesonbuild/meson/issues/1524, but we didn't get any feedback on whether they would actually be useful in real-world usage. I think those were added precisely as a consequence of my discussions with Dylan on porting mesademos. meson subprojects assume too much: they either expect pkg-config, or they expect the subprojects to have source and meson files. Meson does not require pkg-config to find dependencies, but yes we do recommend it because it makes the job very easy. Meson subprojects exist precisely so you can avoid looking outside the source tree for dependencies, so you should not need pkg-config. For instance, you can also create a subproject that exports dependency objects for pre-built binaries just fine. We should publish an example so people know how to do it. Meson is (IMO) unusual in the build systems world in that it's not a static unchangeable upstream (ala cmake/autotools/scons), but is a FOSS project that you can interact with, so please talk to us. :) Well, that's a good and a bad thing. It's certainly great that you're open for discussion. But I'm afraid the fact that so much interaction is necessary means meson still has some ways to go. Honestly, besides filing a couple of bugs, I never felt the need to interact with CMake/SCons development community and driver their direction. It pretty much did what I needed. I don't want to build a build system myself. And I fear living on the bleeding edge myself. In my experience, I really wished that cmake/scons upstream cared a bit more about my use-cases and I didn't have to hack everything I wanted into my build files with macros. ;) I've found cmake projects to be more fragile and harder to understand than even Autotools, but perhaps I'm just looking at badly-written build files. This is one of the reasons why Meson restricts what you can do in a build file — to make it harder for people to write bad ones! I'll be honest, I'm happy to evaluate meson as potential replacement build system for SCons. But to put time in raising meson up to the point where it can be a replacement for SCons is beyond what I'm willing to do. That's fair, but it seems that there are Mesa developers who are interested in doing this, and I do enjoy working with them. The code we get is always high quality. :-) It seems Meson needs a bit more time to mature and grow a more diverse user community. It seems a bit lopsided at the moment. I see no other explanation for us to hit issues with meson that nobody else hit before. Based mostly on contributions, people are using Meson on all Linux distros, all BSDs, Windows, macOS, Solaris, and even Haiku. Talking specifically about Windows issues, some use it via MSYS/Cygwin where these
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Nirbheek Chauhan (2017-09-22 10:47:51) > So it seems to me that wrapping binaries is the only major feature > that is being an obstacle for you to port mesademos? I will publish an > example for doing that via subprojects, that should help! > > Cheers, > Nirbheek That would be very useful. I have wraps for glew and freeglut, but I really don't want to write a wrap for llvm :) Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca wrote: > cmake provides a generic mechanism to set any variable, either from a > command line -DFOO=boo, or via cache files. But meson didn't provide such > standard mechanism AFAICT. > In Meson you must define an option to pass data to the build file. This cannot change since it would go against the basic design principles of Meson. > Furthermore, this needs to work both with pkg-config on Linux, and > non-pkgconfig on Windows. We don't want to have one set of meson files that > use pkconfig subprojects for Linux, and other that use something else for > Windows. > FWIW, a lot of projects use pkg-config on Windows and macOS too since pkg-config is a cross-platform standard. I do understand that it can be a hassle ensuring the existence of pkg-config.exe and convincing some projects that they should add pkg-config files. Perhaps we can improve that by installing a standalone pkg-config.exe with our Windows MSI installers. We also have Windows-specific code in our Sdl2, Boost, Qt, and other dependency search classes which is our preferred mechanism to detect dependencies that are distributed via installers and can be found in 'standard' locations. >> for you, we'd love to talk about how we can improve things. For >> instance, there were these proposals: >> https://github.com/mesonbuild/meson/issues/1525 and >> https://github.com/mesonbuild/meson/issues/1524, but we didn't get any >> feedback on whether they would actually be useful in real-world usage. > > > I think those were added precisely as a consequence of my discussions with > Dylan on porting mesademos. > > meson subprojects assume too much: they either expect pkg-config, or they > expect the subprojects to have source and meson files. > Meson does not require pkg-config to find dependencies, but yes we do recommend it because it makes the job very easy. Meson subprojects exist precisely so you can avoid looking outside the source tree for dependencies, so you should not need pkg-config. For instance, you can also create a subproject that exports dependency objects for pre-built binaries just fine. We should publish an example so people know how to do it. >> Meson is (IMO) unusual in the build systems world in that it's not a >> static unchangeable upstream (ala cmake/autotools/scons), but is a >> FOSS project that you can interact with, so please talk to us. :) > > > Well, that's a good and a bad thing. It's certainly great that you're open > for discussion. But I'm afraid the fact that so much interaction is > necessary means meson still has some ways to go. Honestly, besides filing a > couple of bugs, I never felt the need to interact with CMake/SCons > development community and driver their direction. It pretty much did what I > needed. I don't want to build a build system myself. And I fear living on > the bleeding edge myself. > In my experience, I really wished that cmake/scons upstream cared a bit more about my use-cases and I didn't have to hack everything I wanted into my build files with macros. ;) I've found cmake projects to be more fragile and harder to understand than even Autotools, but perhaps I'm just looking at badly-written build files. This is one of the reasons why Meson restricts what you can do in a build file — to make it harder for people to write bad ones! > I'll be honest, I'm happy to evaluate meson as potential replacement build > system for SCons. But to put time in raising meson up to the point where it > can be a replacement for SCons is beyond what I'm willing to do. > That's fair, but it seems that there are Mesa developers who are interested in doing this, and I do enjoy working with them. The code we get is always high quality. :-) > It seems Meson needs a bit more time to mature and grow a more diverse user > community. It seems a bit lopsided at the moment. I see no other > explanation for us to hit issues with meson that nobody else hit before. > Based mostly on contributions, people are using Meson on all Linux distros, all BSDs, Windows, macOS, Solaris, and even Haiku. Talking specifically about Windows issues, some use it via MSYS/Cygwin where these are not problems, others use MSVC and work around these issues via the mechanisms I mentioned above or they just bite the bullet and port all their dependencies to Meson. > I do think that wrap patches have lot of potential. Thanks for the kind words! I'm glad you see what we're aiming for. :) > And there was a fullly > working wrap paych for glew/freeglut ready to use it would have been a > godsend. But there wasn't. And they are simply too much for a beginner, or > for a team of people to collaborate, specially because they are maintained > off tree. > So it seems to me that wrapping binaries is the only major feature that is being an obstacle for you to port mesademos? I will publish an example for doing that via subprojects, that should help! Cheers, Nirbheek ___
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 21/09/17 09:56, Nirbheek Chauhan wrote: On Thu, Sep 21, 2017 at 1:53 PM, Jose Fonseca wrote: On 12/04/17 18:57, Nirbheek Chauhan wrote: Hi Jose, On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca wrote: One newbie question: what's your workflow to update a wrap patch? Can we prototype changes locally without tarballing the patch? Any changes you make in subproject directories will be kept as-is; Meson only initializes them and will not try to update them (yet), so you can apply your patches to the subproject directory manually for testing. In the future, we want to improve this workflow, of course. Hi Dylan, FYI I didn't forget about this. But I have to say that having to maintain and fix these wrap modules seperately from git is simply a huge turn off everytime I think about resuming this. I think it's was a mistake to try to make meson wrap modules for 3rd party dependencies. Especially when these wrap modules involve glue that's not tracked in git, so it can't be esasily revved, or shared across the people working on this. If we simply had a way to consumed built binaries like we can easily do with cmake, I'm confident it would have been trivial to get this going by now. But as it stands I don't think overcome this wall. Honestly, I don't want have to deal with porting glew/freeglut to meson just to get mesademos with meson, and I really shouldn't have to. I don't want to build the world just mesademos. That is not a requirement in general, only a requirement if you want to use glew/freeglut as a subproject (which requires meson build files). Meson will be able to find libraries stored anywhere on the system as long as you either: a) Set the correct env variables for the compiler library and include paths[1], or b) Set the `dirs:` keyword argument to cc.find_library() and set the right include paths, or c) Set PKG_CONFIG_PATH if your libraries ship pkg-config files This is very similar to cmake, fwict. cmake provides a generic mechanism to set any variable, either from a command line -DFOO=boo, or via cache files. But meson didn't provide such standard mechanism AFAICT. Furthermore, this needs to work both with pkg-config on Linux, and non-pkgconfig on Windows. We don't want to have one set of meson files that use pkconfig subprojects for Linux, and other that use something else for Windows. However, if this doesn't work for you, we'd love to talk about how we can improve things. For instance, there were these proposals: https://github.com/mesonbuild/meson/issues/1525 and https://github.com/mesonbuild/meson/issues/1524, but we didn't get any feedback on whether they would actually be useful in real-world usage. I think those were added precisely as a consequence of my discussions with Dylan on porting mesademos. meson subprojects assume too much: they either expect pkg-config, or they expect the subprojects to have source and meson files. Meson is (IMO) unusual in the build systems world in that it's not a static unchangeable upstream (ala cmake/autotools/scons), but is a FOSS project that you can interact with, so please talk to us. :) Well, that's a good and a bad thing. It's certainly great that you're open for discussion. But I'm afraid the fact that so much interaction is necessary means meson still has some ways to go. Honestly, besides filing a couple of bugs, I never felt the need to interact with CMake/SCons development community and driver their direction. It pretty much did what I needed. I don't want to build a build system myself. And I fear living on the bleeding edge myself. I'll be honest, I'm happy to evaluate meson as potential replacement build system for SCons. But to put time in raising meson up to the point where it can be a replacement for SCons is beyond what I'm willing to do. It seems Meson needs a bit more time to mature and grow a more diverse user community. It seems a bit lopsided at the moment. I see no other explanation for us to hit issues with meson that nobody else hit before. The main advantage of adding a wrap patch for a project is to speed up (and make it easy to have) integration builds that build the entire stack, but the most common usage of Meson is to build against pre-existing binaries. We could probably make the experience better on Windows, but we need feedback to do that! Cheers, Nirbheek 1. `LIB`/`INCLUDE` with MSVC and `LIBRARY_PATH`/`C_INCLUDE_PATH` for gcc/clang I do think that wrap patches have lot of potential. And there was a fullly working wrap paych for glew/freeglut ready to use it would have been a godsend. But there wasn't. And they are simply too much for a beginner, or for a team of people to collaborate, specially because they are maintained off tree. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 12/04/17 18:57, Nirbheek Chauhan wrote: Hi Jose, On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca wrote: One newbie question: what's your workflow to update a wrap patch? Can we prototype changes locally without tarballing the patch? Any changes you make in subproject directories will be kept as-is; Meson only initializes them and will not try to update them (yet), so you can apply your patches to the subproject directory manually for testing. In the future, we want to improve this workflow, of course. Hi Dylan, FYI I didn't forget about this. But I have to say that having to maintain and fix these wrap modules seperately from git is simply a huge turn off everytime I think about resuming this. I think it's was a mistake to try to make meson wrap modules for 3rd party dependencies. Especially when these wrap modules involve glue that's not tracked in git, so it can't be esasily revved, or shared across the people working on this. If we simply had a way to consumed built binaries like we can easily do with cmake, I'm confident it would have been trivial to get this going by now. But as it stands I don't think overcome this wall. Honestly, I don't want have to deal with porting glew/freeglut to meson just to get mesademos with meson, and I really shouldn't have to. I don't want to build the world just mesademos. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On Thu, Sep 21, 2017 at 1:53 PM, Jose Fonseca wrote: > On 12/04/17 18:57, Nirbheek Chauhan wrote: >> >> Hi Jose, >> >> On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca >> wrote: >>> >>> One newbie question: what's your workflow to update a wrap patch? Can we >>> prototype changes locally without tarballing the patch? >>> >> >> Any changes you make in subproject directories will be kept as-is; >> Meson only initializes them and will not try to update them (yet), so >> you can apply your patches to the subproject directory manually for >> testing. >> >> In the future, we want to improve this workflow, of course. >> > > Hi Dylan, > > FYI I didn't forget about this. But I have to say that having to maintain > and fix these wrap modules seperately from git is simply a huge turn off > everytime I think about resuming this. > > I think it's was a mistake to try to make meson wrap modules for 3rd party > dependencies. Especially when these wrap modules involve glue that's not > tracked in git, so it can't be esasily revved, or shared across the people > working on this. If we simply had a way to consumed built binaries like we > can easily do with cmake, I'm confident it would have been trivial to get > this going by now. > > But as it stands I don't think overcome this wall. Honestly, I don't want > have to deal with porting glew/freeglut to meson just to get mesademos with > meson, and I really shouldn't have to. I don't want to build the world just > mesademos. > That is not a requirement in general, only a requirement if you want to use glew/freeglut as a subproject (which requires meson build files). Meson will be able to find libraries stored anywhere on the system as long as you either: a) Set the correct env variables for the compiler library and include paths[1], or b) Set the `dirs:` keyword argument to cc.find_library() and set the right include paths, or c) Set PKG_CONFIG_PATH if your libraries ship pkg-config files This is very similar to cmake, fwict. However, if this doesn't work for you, we'd love to talk about how we can improve things. For instance, there were these proposals: https://github.com/mesonbuild/meson/issues/1525 and https://github.com/mesonbuild/meson/issues/1524, but we didn't get any feedback on whether they would actually be useful in real-world usage. Meson is (IMO) unusual in the build systems world in that it's not a static unchangeable upstream (ala cmake/autotools/scons), but is a FOSS project that you can interact with, so please talk to us. :) The main advantage of adding a wrap patch for a project is to speed up (and make it easy to have) integration builds that build the entire stack, but the most common usage of Meson is to build against pre-existing binaries. We could probably make the experience better on Windows, but we need feedback to do that! Cheers, Nirbheek 1. `LIB`/`INCLUDE` with MSVC and `LIBRARY_PATH`/`C_INCLUDE_PATH` for gcc/clang ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Jose Fonseca (2017-04-12 10:38:11) > Dylan, Nirbheek, > > Thanks for the info. > > I made a bit more progress. > > One newbie question: what's your workflow to update a wrap patch? Can we > prototype changes locally without tarballing the patch? Yes, you can just update the meson.build script in subprojects/libfoo/ and rebuild. What I've been doing is (in a clean directory) unpacking the source, then unpacking my wrap on top of that and hacking on it until I have it working, then copy my changes back into a clean source tree to build the tarball. I think this is more convenient since it allows me to just work on one wrap at a time without dealing with mesa-demos or any other wraps. > > One request: would it be possible to update the compiler args for both c and > c++ with a single statement? (Maybe accept a list of languages instead of a > single language?) If you're talking about add_project_arguments then a patch landed a few days ago: https://github.com/mesonbuild/meson/pull/1580, and will work if using meson from git (like we are currently). Dylan > > Jose signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Hi Jose, On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca wrote: > One newbie question: what's your workflow to update a wrap patch? Can we > prototype changes locally without tarballing the patch? > Any changes you make in subproject directories will be kept as-is; Meson only initializes them and will not try to update them (yet), so you can apply your patches to the subproject directory manually for testing. In the future, we want to improve this workflow, of course. > One request: would it be possible to update the compiler args for both c and > c++ with a single statement? (Maybe accept a list of languages instead of a > single language?) > Yes, I believe someone else also requested that and it should be really easy to add via a new kwarg called 'languages:`: https://github.com/mesonbuild/meson/issues/1615 Cheers, Nirbheek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Dylan, Nirbheek, Thanks for the info. I made a bit more progress. One newbie question: what's your workflow to update a wrap patch? Can we prototype changes locally without tarballing the patch? One request: would it be possible to update the compiler args for both c and c++ with a single statement? (Maybe accept a list of languages instead of a single language?) Jose From: Dylan Baker Sent: Tuesday, April 11, 2017 2:04:20 AM To: Jose Fonseca; Nirbheek Chauhan Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson) Quoting Dylan Baker (2017-04-10 11:50:36) > Quoting Nirbheek Chauhan (2017-04-10 06:59:02) > > Hello Jose, > > > > On Mon, Apr 10, 2017 at 5:41 PM, Jose Fonseca wrote: > > > I've been trying to get native mingw to build. (It's still important to > > > prototype mesademos with MSVC to ensure meson is up to the task, but long > > > term, I think I'll push for dropping MSVC support from mesademos and > > > piglit, > > > since MinGW is fine for this sort of samples/tests programs.) > > > > > > However native MinGW fails poorly: > > > > > > [78/1058] Static linking library src/util/libutil.a > > > FAILED: src/util/libutil.a > > > cmd /c del /f /s /q src/util/libutil.a && ar @src/util/libutil.a.rsp > > > Invalid switch - "util". > > > > > > So the problem here is that meson is passing `/` separator to the cmd.exe > > > del command, instead of `\`. > > > > > > Full log > > > https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/6rpen94u7yq3q69n > > > > > > > This was a regression with 0.39, and is already fixed in git master: > > https://github.com/mesonbuild/meson/pull/1527 > > > > It will be in the next release, which is scheduled for April 22. In > > the meantime, please test with git master. > > > > > > > > TBH, this is basic windows functionality, and if it can't get it right > > > then > > > it shakes my belief that's it's getting proper windows testing... > > > > > > > I'm sorry to hear that. > > > > > > > > I think part of the problem is that per > > > https://github.com/mesonbuild/meson/blob/master/.appveyor.yml Meson is > > > only > > > being tested with MSYS (which provides a full-blow POSIX environment on > > > Windows), and not with plain MinGW. > > > > > > > Actually, this slipped through the cracks (I broke it!) because we > > didn't have our CI testing MinGW. Now we do, specifically to catch > > this sort of stuff: https://github.com/mesonbuild/meson/pull/1346. > > > > All our pull requests are required to pass all CI before they can be > > merged, and every bug fixed and feature added is required to have a > > new test case for it, so I expect the situation will not regress > > again. > > > > Our CI is fairly comprehensive -- MSVC 2010, 2015, 2017, MinGW, Cygwin > > on just Windows and getting better every day. The biggest hole in it > > right now is BSD, and we would be extremely grateful if someone could > > help us with that too! > > > > > IMHO, MSYS is a hack to get packages that use autotools to build with > > > MinGW. > > > Packages that use Windows aware build systems (like Meson is trying to be) > > > should stay as _far_ as possible from MSYS > > > > > > > Yes, I agree. MSYS2 in particular is especially broken (the toolchain > > is buggy and even the python3 shipped with it is crap) and we do not > > recommend using it at all (although a surprisingly large number of > > people use its toolchain, so we do support it). If you look closely, > > we do not use MSYS itself, only MinGW: > > > > https://github.com/mesonbuild/meson/blob/master/.appveyor.yml#L61 > > > > The MSYS paths are C:\msys64\usr\bin and the MinGW (toolchain) paths > > are C:\msys64\mingw??\bin. > > > > And in any case our codepaths for building something with the Ninja > > backend on MSVC and MinGW are almost identical, and our MSVC CI does > > not have any POSIX binaries in their path. > > > > I even have all of Glib + dependencies building out of the box with > > just Meson git + MSVC [https://github.com/centricular/glib/], and my > > next step is to have all of GStreamer building that way. > > > > Hope this clarifies things! > > > > Cheers, > > Nirbheek > > Jose, > >
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Dylan Baker (2017-04-10 11:50:36) > Quoting Nirbheek Chauhan (2017-04-10 06:59:02) > > Hello Jose, > > > > On Mon, Apr 10, 2017 at 5:41 PM, Jose Fonseca wrote: > > > I've been trying to get native mingw to build. (It's still important to > > > prototype mesademos with MSVC to ensure meson is up to the task, but long > > > term, I think I'll push for dropping MSVC support from mesademos and > > > piglit, > > > since MinGW is fine for this sort of samples/tests programs.) > > > > > > However native MinGW fails poorly: > > > > > > [78/1058] Static linking library src/util/libutil.a > > > FAILED: src/util/libutil.a > > > cmd /c del /f /s /q src/util/libutil.a && ar @src/util/libutil.a.rsp > > > Invalid switch - "util". > > > > > > So the problem here is that meson is passing `/` separator to the cmd.exe > > > del command, instead of `\`. > > > > > > Full log > > > https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/6rpen94u7yq3q69n > > > > > > > This was a regression with 0.39, and is already fixed in git master: > > https://github.com/mesonbuild/meson/pull/1527 > > > > It will be in the next release, which is scheduled for April 22. In > > the meantime, please test with git master. > > > > > > > > TBH, this is basic windows functionality, and if it can't get it right > > > then > > > it shakes my belief that's it's getting proper windows testing... > > > > > > > I'm sorry to hear that. > > > > > > > > I think part of the problem is that per > > > https://github.com/mesonbuild/meson/blob/master/.appveyor.yml Meson is > > > only > > > being tested with MSYS (which provides a full-blow POSIX environment on > > > Windows), and not with plain MinGW. > > > > > > > Actually, this slipped through the cracks (I broke it!) because we > > didn't have our CI testing MinGW. Now we do, specifically to catch > > this sort of stuff: https://github.com/mesonbuild/meson/pull/1346. > > > > All our pull requests are required to pass all CI before they can be > > merged, and every bug fixed and feature added is required to have a > > new test case for it, so I expect the situation will not regress > > again. > > > > Our CI is fairly comprehensive -- MSVC 2010, 2015, 2017, MinGW, Cygwin > > on just Windows and getting better every day. The biggest hole in it > > right now is BSD, and we would be extremely grateful if someone could > > help us with that too! > > > > > IMHO, MSYS is a hack to get packages that use autotools to build with > > > MinGW. > > > Packages that use Windows aware build systems (like Meson is trying to be) > > > should stay as _far_ as possible from MSYS > > > > > > > Yes, I agree. MSYS2 in particular is especially broken (the toolchain > > is buggy and even the python3 shipped with it is crap) and we do not > > recommend using it at all (although a surprisingly large number of > > people use its toolchain, so we do support it). If you look closely, > > we do not use MSYS itself, only MinGW: > > > > https://github.com/mesonbuild/meson/blob/master/.appveyor.yml#L61 > > > > The MSYS paths are C:\msys64\usr\bin and the MinGW (toolchain) paths > > are C:\msys64\mingw??\bin. > > > > And in any case our codepaths for building something with the Ninja > > backend on MSVC and MinGW are almost identical, and our MSVC CI does > > not have any POSIX binaries in their path. > > > > I even have all of Glib + dependencies building out of the box with > > just Meson git + MSVC [https://github.com/centricular/glib/], and my > > next step is to have all of GStreamer building that way. > > > > Hope this clarifies things! > > > > Cheers, > > Nirbheek > > Jose, > > I installed meson from git as Nirbheek suggested, and it got the mingw build > working, and fixed the appveyor build to actually start, although I ran into > some problems with freeglut I'm not sure if I'll have time to fix today > (although I'd like to get them fixed). If you pull my branch both the travis > build will turn completely green, and the MinGW build turns green on appveyor, > though MSVC still doesn't. My meson branch is based on yours and you should be > able to apply the changes cleanly. I have freeglut building, but we're waiting for a patch to land in meson for getting vs_modules_defs to take generated files (which we need for either glew or freeglut, I can't remember which off the top of my head) (and nirbheek was so kind as to review). Assuming that my patch lands today you may be able to get started on msvc for mesa-demos itself, or we may need to to a little more work to get freeglut and/or glew building on msvc. You'll probably want to either pull my meson branch, or at least look at to get these fixes. without the updated freeglut patch meson will fail to build when it fails the sha256 check. Thank you for setting up appveyor support, btw. In lieu of a real windows install with visual studio it's been very helpful, but I've never figured out how to configure it for C/C++ projects. Here's the pat
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Nirbheek Chauhan (2017-04-10 06:59:02) > Hello Jose, > > On Mon, Apr 10, 2017 at 5:41 PM, Jose Fonseca wrote: > > I've been trying to get native mingw to build. (It's still important to > > prototype mesademos with MSVC to ensure meson is up to the task, but long > > term, I think I'll push for dropping MSVC support from mesademos and piglit, > > since MinGW is fine for this sort of samples/tests programs.) > > > > However native MinGW fails poorly: > > > > [78/1058] Static linking library src/util/libutil.a > > FAILED: src/util/libutil.a > > cmd /c del /f /s /q src/util/libutil.a && ar @src/util/libutil.a.rsp > > Invalid switch - "util". > > > > So the problem here is that meson is passing `/` separator to the cmd.exe > > del command, instead of `\`. > > > > Full log > > https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/6rpen94u7yq3q69n > > > > This was a regression with 0.39, and is already fixed in git master: > https://github.com/mesonbuild/meson/pull/1527 > > It will be in the next release, which is scheduled for April 22. In > the meantime, please test with git master. > > > > > TBH, this is basic windows functionality, and if it can't get it right then > > it shakes my belief that's it's getting proper windows testing... > > > > I'm sorry to hear that. > > > > > I think part of the problem is that per > > https://github.com/mesonbuild/meson/blob/master/.appveyor.yml Meson is only > > being tested with MSYS (which provides a full-blow POSIX environment on > > Windows), and not with plain MinGW. > > > > Actually, this slipped through the cracks (I broke it!) because we > didn't have our CI testing MinGW. Now we do, specifically to catch > this sort of stuff: https://github.com/mesonbuild/meson/pull/1346. > > All our pull requests are required to pass all CI before they can be > merged, and every bug fixed and feature added is required to have a > new test case for it, so I expect the situation will not regress > again. > > Our CI is fairly comprehensive -- MSVC 2010, 2015, 2017, MinGW, Cygwin > on just Windows and getting better every day. The biggest hole in it > right now is BSD, and we would be extremely grateful if someone could > help us with that too! > > > IMHO, MSYS is a hack to get packages that use autotools to build with MinGW. > > Packages that use Windows aware build systems (like Meson is trying to be) > > should stay as _far_ as possible from MSYS > > > > Yes, I agree. MSYS2 in particular is especially broken (the toolchain > is buggy and even the python3 shipped with it is crap) and we do not > recommend using it at all (although a surprisingly large number of > people use its toolchain, so we do support it). If you look closely, > we do not use MSYS itself, only MinGW: > > https://github.com/mesonbuild/meson/blob/master/.appveyor.yml#L61 > > The MSYS paths are C:\msys64\usr\bin and the MinGW (toolchain) paths > are C:\msys64\mingw??\bin. > > And in any case our codepaths for building something with the Ninja > backend on MSVC and MinGW are almost identical, and our MSVC CI does > not have any POSIX binaries in their path. > > I even have all of Glib + dependencies building out of the box with > just Meson git + MSVC [https://github.com/centricular/glib/], and my > next step is to have all of GStreamer building that way. > > Hope this clarifies things! > > Cheers, > Nirbheek Jose, I installed meson from git as Nirbheek suggested, and it got the mingw build working, and fixed the appveyor build to actually start, although I ran into some problems with freeglut I'm not sure if I'll have time to fix today (although I'd like to get them fixed). If you pull my branch both the travis build will turn completely green, and the MinGW build turns green on appveyor, though MSVC still doesn't. My meson branch is based on yours and you should be able to apply the changes cleanly. signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Hello Jose, On Mon, Apr 10, 2017 at 5:41 PM, Jose Fonseca wrote: > I've been trying to get native mingw to build. (It's still important to > prototype mesademos with MSVC to ensure meson is up to the task, but long > term, I think I'll push for dropping MSVC support from mesademos and piglit, > since MinGW is fine for this sort of samples/tests programs.) > > However native MinGW fails poorly: > > [78/1058] Static linking library src/util/libutil.a > FAILED: src/util/libutil.a > cmd /c del /f /s /q src/util/libutil.a && ar @src/util/libutil.a.rsp > Invalid switch - "util". > > So the problem here is that meson is passing `/` separator to the cmd.exe > del command, instead of `\`. > > Full log > https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/6rpen94u7yq3q69n > This was a regression with 0.39, and is already fixed in git master: https://github.com/mesonbuild/meson/pull/1527 It will be in the next release, which is scheduled for April 22. In the meantime, please test with git master. > > TBH, this is basic windows functionality, and if it can't get it right then > it shakes my belief that's it's getting proper windows testing... > I'm sorry to hear that. > > I think part of the problem is that per > https://github.com/mesonbuild/meson/blob/master/.appveyor.yml Meson is only > being tested with MSYS (which provides a full-blow POSIX environment on > Windows), and not with plain MinGW. > Actually, this slipped through the cracks (I broke it!) because we didn't have our CI testing MinGW. Now we do, specifically to catch this sort of stuff: https://github.com/mesonbuild/meson/pull/1346. All our pull requests are required to pass all CI before they can be merged, and every bug fixed and feature added is required to have a new test case for it, so I expect the situation will not regress again. Our CI is fairly comprehensive -- MSVC 2010, 2015, 2017, MinGW, Cygwin on just Windows and getting better every day. The biggest hole in it right now is BSD, and we would be extremely grateful if someone could help us with that too! > IMHO, MSYS is a hack to get packages that use autotools to build with MinGW. > Packages that use Windows aware build systems (like Meson is trying to be) > should stay as _far_ as possible from MSYS > Yes, I agree. MSYS2 in particular is especially broken (the toolchain is buggy and even the python3 shipped with it is crap) and we do not recommend using it at all (although a surprisingly large number of people use its toolchain, so we do support it). If you look closely, we do not use MSYS itself, only MinGW: https://github.com/mesonbuild/meson/blob/master/.appveyor.yml#L61 The MSYS paths are C:\msys64\usr\bin and the MinGW (toolchain) paths are C:\msys64\mingw??\bin. And in any case our codepaths for building something with the Ninja backend on MSVC and MinGW are almost identical, and our MSVC CI does not have any POSIX binaries in their path. I even have all of Glib + dependencies building out of the box with just Meson git + MSVC [https://github.com/centricular/glib/], and my next step is to have all of GStreamer building that way. Hope this clarifies things! Cheers, Nirbheek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 08/04/17 23:07, Jose Fonseca wrote: On 08/04/17 00:24, Dylan Baker wrote: Quoting Jose Fonseca (2017-03-30 15:19:31) Cool. BTW, another alternative (for things like LLVM) would be to chain build systems (ie, have a wrap that builds LLVM invoking CMake) Jose I have no idea whether chaining would work or not, that would be an interesting thing to try. I have force pushed to the meson branch. Things are building on Linux with both mingw, gcc, and clang. I've wrapped freeglut and glew, and pulled out the epoxy stuff. The mingw cross build does rely on an unmerged patch (that is approved, just awaiting merge) for mingw windres support in the cross file. That shouldn't be a problem for msvc or building natively with mingw. I have not done any of the msvc work or either mesa-demos or for freeglut or glew. Hopefully this gets things far enough along that you can get msvc going when you have some time. Dylan Thanks. I hit an errors early on with MSVC. I fixed a few, but I didn't spend much time on it. Instead I added AppVeyor integration so anybody can experiment. https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/qysf73s4975i2w36 https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=meson-appveyor I had to push to a private git repos since I'd need a FDO admin to install Appveyor hook on the official mesa demos repo. I'll get that going but it'll probably take time. Given you use Github, it should be trivial to hook Appveyor on your mesademos repos in github. Jose I've been trying to get native mingw to build. (It's still important to prototype mesademos with MSVC to ensure meson is up to the task, but long term, I think I'll push for dropping MSVC support from mesademos and piglit, since MinGW is fine for this sort of samples/tests programs.) However native MinGW fails poorly: [78/1058] Static linking library src/util/libutil.a FAILED: src/util/libutil.a cmd /c del /f /s /q src/util/libutil.a && ar @src/util/libutil.a.rsp Invalid switch - "util". So the problem here is that meson is passing `/` separator to the cmd.exe del command, instead of `\`. Full log https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/6rpen94u7yq3q69n TBH, this is basic windows functionality, and if it can't get it right then it shakes my belief that's it's getting proper windows testing... I think part of the problem is that per https://github.com/mesonbuild/meson/blob/master/.appveyor.yml Meson is only being tested with MSYS (which provides a full-blow POSIX environment on Windows), and not with plain MinGW. IMHO, MSYS is a hack to get packages that use autotools to build with MinGW. Packages that use Windows aware build systems (like Meson is trying to be) should stay as _far_ as possible from MSYS Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 08/04/17 00:24, Dylan Baker wrote: Quoting Jose Fonseca (2017-03-30 15:19:31) Cool. BTW, another alternative (for things like LLVM) would be to chain build systems (ie, have a wrap that builds LLVM invoking CMake) Jose I have no idea whether chaining would work or not, that would be an interesting thing to try. I have force pushed to the meson branch. Things are building on Linux with both mingw, gcc, and clang. I've wrapped freeglut and glew, and pulled out the epoxy stuff. The mingw cross build does rely on an unmerged patch (that is approved, just awaiting merge) for mingw windres support in the cross file. That shouldn't be a problem for msvc or building natively with mingw. I have not done any of the msvc work or either mesa-demos or for freeglut or glew. Hopefully this gets things far enough along that you can get msvc going when you have some time. Dylan Thanks. I hit an errors early on with MSVC. I fixed a few, but I didn't spend much time on it. Instead I added AppVeyor integration so anybody can experiment. https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/qysf73s4975i2w36 https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=meson-appveyor I had to push to a private git repos since I'd need a FDO admin to install Appveyor hook on the official mesa demos repo. I'll get that going but it'll probably take time. Given you use Github, it should be trivial to hook Appveyor on your mesademos repos in github. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Jose Fonseca (2017-03-30 15:19:31) > > Cool. BTW, another alternative (for things like LLVM) would be to > chain build systems (ie, have a wrap that builds LLVM invoking CMake) > > Jose > I have no idea whether chaining would work or not, that would be an interesting thing to try. I have force pushed to the meson branch. Things are building on Linux with both mingw, gcc, and clang. I've wrapped freeglut and glew, and pulled out the epoxy stuff. The mingw cross build does rely on an unmerged patch (that is approved, just awaiting merge) for mingw windres support in the cross file. That shouldn't be a problem for msvc or building natively with mingw. I have not done any of the msvc work or either mesa-demos or for freeglut or glew. Hopefully this gets things far enough along that you can get msvc going when you have some time. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 30/03/17 19:52, Dylan Baker wrote:
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
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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,
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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)
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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 to
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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 depe
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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 windo
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
On 03/28/2017 11:19 AM, Dylan Baker wrote: Quoting Jose Fonseca (2017-03-28 09:19:48) On 28/03/17 00:12, Dylan Baker wrote: 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. Is freeglut a hard requirement? At least in autoconf we have logic to look for both, and use #defines to enable freeglut only features. Nearly all the Mesa demos require GLUT / freeglut. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Quoting Jose Fonseca (2017-03-28 09:19:48) > On 28/03/17 00:12, Dylan Baker wrote: > > > > 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. Is freeglut a hard requirement? At least in autoconf we have logic to look for both, and use #defines to enable freeglut only features. > > > 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) > I assumed it was probably something like that. I'll have a look. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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 defi
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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
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
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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 a port to libepoxy that works on linux, using it as a subproject is
turning out to be rather difficult, in part because of the way that the libepoxy
meson is written. I'm hoping to spend some more time on this tonight, but I'm
not sure I have time.
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
Jose Fonseca writes:
> 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..
libepoxy does "keep a vtable of resolved functions per context, wrap
wglMakeCurrent to trigger re-resolve when we change contexts". For
handling things like glut's wglMakeCurrent, there's a public
epoxy_handle_external_wglMakeCurrent() function you can call.
If you use glut and fail to call epoxy_handle_external_wglMakeCurrent(),
you'll end up with resolution inside the global function pointers, which
is going to be fine if you only ever have one context in glut.
There's a note for "we should probably track the resolved functions per
context rather than throwing out resolution on every MakeCurrent", but
I don't actually know if anyone wants that.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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.
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)
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. 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.
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")
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
