[Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Jose Fonseca]

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 <jfonseca at 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