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 <jfons...@vmware.com> 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 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! > > Yes, for mesademos that's the major obstacle I see. Thanks. > > Jose >
Jose, Slightly related question, do you guys build LLVM yourselves, or use precompiled binaries from somewhere (and if that's the case where do you get them from)? Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
