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.
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!
