Re: [Mesa-dev] Rust drivers in Mesa

[Nirbheek Chauhan]

On Fri, Oct 2, 2020 at 8:35 PM Dylan Baker  wrote:
>
> Add a meson developer the rust community has been incredibly hard to work with
> and basically hostile to every request we've made "cargo is hour you build 
> rust",
> is essentially the answer we've gotten from them at every turn.
>
> On the meson front cargo is incredibly hard to integrate with meson, it's
> essentially like calling cmake in autotools.
>

Also speaking as a meson developer, I'd like to share another point of view.

As of today, Meson's integration with Cargo is not great. The only
option you have is what Fractal does, as pointed out by Alyssa.
However, I believe that the status quo is (at least in part) a
consequence of us not merging the "unstable-cargo" Meson module[1] I
wrote back in 2017.

At the time we did not have a well-defined way to integrate Meson with
other build systems, but now we do. I think we can give that another
shot. The integration in that PR is not perfect, but it's the best
start we can get. Mostly because we need to do quite some work on
Cargo to make information available, standardization of some features
used in build.rs, and so on. Some of this has already begun[2].

But setting all this aside, as Alyssa has already mentioned, you do
not need Cargo to use Rust, and Meson already supports that use-case.
You can compile and link Rust code like you would C or C++ code using
Meson today. I think this can be a good fit for Mesa.

Overall, my point of view is that as non-contributors,
non-participants, and non-users, we have no voice in the future of
Cargo or Rust. I can completely understand why it has been hard to
work with them; it would be the same with any other FOSS project. The
fix is straightforward: start using it, start participating, and
*then* we will be in a position to complain and work together in
making change happen.

The fundamental property of software is that no one fixes anything
till someone really wants it fixed.

Cheers,
Nirbheek

1. https://github.com/mesonbuild/meson/pull/2617
2. https://docs.rs/system-deps/1.3.1/system_deps/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/4] meson: build "radv" vulkan driver for radeon hardware

[Nirbheek Chauhan]

On Wed, Sep 27, 2017 at 1:11 AM, Dylan Baker <dy...@pnwbakers.com> wrote:
> Quoting Nirbheek Chauhan (2017-09-26 12:29:30)
>> On Tue, Sep 26, 2017 at 9:46 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
>> > This builds and installs, but I haven't had a chance to test it yet.
>> >
>> > v2: - enable radv by default
>> > - add shader cache support and enforce that it's built for radv
>> > v3: - Fix typo in meson_options (Nicholas)
>> > - strip trailing 'svn' from llvm version before setting the version
>> >   preprocessor flag (Bas)
>>
>> Should this also be added to the LLVMDependency meson class?
>
> I was looking at that. I'm not sure since I think that 6.0.0svn *should* <
> 6.0.0, but meson just throws the svn away when it does the comparison.

That's version_compare(), which should perhaps follow rpm's version
comparison algorithm[1], since that is also what pkg-config and many
other package managers use, but in practice almost all libraries use
semantic versioning (which is what it implements right now).

For the LLVMDependency class, as a start I think we could strip the
'svn' from the version since most things aren't really ready for alpha
to be present in version numbers. It's up to you though, since you
wrote the class and are more familiar with llvm itself.

1. http://blog.jasonantman.com/2014/07/how-yum-and-rpm-compare-versions/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/4] meson: build "radv" vulkan driver for radeon hardware

[Nirbheek Chauhan]

On Tue, Sep 26, 2017 at 9:46 PM, Dylan Baker  wrote:
> This builds and installs, but I haven't had a chance to test it yet.
>
> v2: - enable radv by default
> - add shader cache support and enforce that it's built for radv
> v3: - Fix typo in meson_options (Nicholas)
> - strip trailing 'svn' from llvm version before setting the version
>   preprocessor flag (Bas)

Should this also be added to the LLVMDependency meson class?
___
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)

[Nirbheek Chauhan]

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,

Re: [Mesa-dev] initial meson port

[Nirbheek Chauhan]

On Thu, Sep 21, 2017 at 5:36 PM, Jakob Bornecrantz  wrote:
> Wasn't lacking distcheck support one of the arguments against moving
> to only a scons build when this was brought up all those years ago?
> Does Meson provide something similar, or do people just now get all
> of the source from git nowadays?
>

Meson supports a `dist` feature which is the same as `distcheck`.
However, it is less error-prone compared to Autotools distcheck
because it will tarball everything that has been checked into git
(once tests pass), so you don't have to maintain a whitelist of files.

This also means that you can be sure that your release contains the
same code that your git repository contains, and hence that your
release is buildable from both git and the tarball.

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)

[Nirbheek Chauhan]

On Thu, Sep 21, 2017 at 1:53 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> On 12/04/17 18:57, Nirbheek Chauhan wrote:
>>
>> Hi Jose,
>>
>> On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca <jfons...@vmware.com>
>> 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)

[Nirbheek Chauhan]

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)

[Nirbheek Chauhan]

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