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 <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 > > Hi Dylan, > > We build LLVM ourselves, from a branch with som backported fixeds, > https://cgit.freedesktop.org/~jrfonseca/llvm/commit/?h=backports_33 . > > There are build instructions on mesa/docs/llvmpipe.html > > But I also include a precompiled tarball for MSVC on > https://people.freedesktop.org/~jrfonseca/llvm/ This is what gets used > in mesa/appveyor.yml > > Jose
Thanks!
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
