On 21/09/17 09:56, Nirbheek Chauhan wrote:
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.
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
