[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hi Kai,

Quoting Kai Wasserbäch (2017-03-21 09:50:52)
> Hey Dylan,
> I've just a few points, since I'm not too enthused by the prospect of having to
> deal with yet another build system with yet another slightly different syntax.
> But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
> involved with Mesa and their opinion is what matters in the end. Anyway, here
> goes nothing.
> 
> This might be a dumb question but isn't Meson (through wrap files) one of the
> build systems that download crap from all over the internet silently? Ie. making
> a packager's/distribution's life hell? There is
> <https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual#toggling-between-distro-packages-and-embedded-source>
> but that seems to imply a silent fallback to downloading stuff. I would rather
> have a configure step that fails if a dependency is not met instead of building
> something that can't be distributed. Or is there a magic "--distribution-build"
> flag? If there isn't I would rather see a switch to CMake (as others have
> pointed out in this thread: many projects in the vicinity of Mesa already use
> CMake), but I get that there's a lot of hate for CMake (even though the Meson
> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
> would be unlikely.

I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
aimed at windows and osx, where bundling is the norm, and not Linux and the BSDs
where it's not. What I would expect if the windows guys wanted to use wrap is
that we would have something like this:

if host_machine.system() != 'windows'
    dep_zlib = dependency('zlib', version : '>1.0.0')
else
    subproj_zlib = subproject('zlib')
    dep_zlib = subproj_zlib.get_variable('zlib_dep')
endif

Which would make the dependency a hard requirement for non-windows system (i.e.
the configure fails if zlib isn't found *except* on windows), and windows could
fall back to wraps.

I have no plans to implement wrap for mesa in the port I would do, and would NAK
any patches that used wrap on Linux or BSD. The windows devs can make their own
choice on how to handle dependencies (I have no idea what their development
environment looks like and don't want to make that choice for them). I agree
with you it's not the way that Linux or BSD works, we have competent package
management solutions without the need to automatically download sources.

As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
and cmake are the difference between python and perl, there may be some
superficial similarities, but they are *not* the same. One of the things I'll
reiterate that impressed me the most about meson is that it's syntax is simple,
not Turring-complete, and opinionated.

In fact, piglit is the best reason not not use cmake I can come up with. There
is an (admittedly clever) hack to allow building tests for each of the API's
supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
each API, which means you can't put things in the tests directory that can only
be run once. Every time I try to make changes to the Cmake I spend about an hour
trying to figure out why some code I've implemented doesn't work, only to
remember that. Build systems aren't programming languages, they shouldn't be
interesting, they should be declarative; cmake is a full scripting language with
enough warts to make bash look cuddly.

> 
> Dylan Baker wrote on 16.03.2017 22:25:
> > Why bother, and why would we want this?
> > 
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently.
> 
> Well, CMake (and probably others), see
> <https://cmake.org/cmake/help/latest/generator/Ninja.html>, can use/generate for
> ninja too.

Sure, I think we've gone over this in the rather long thread, ninja is really
just a "nice to have" since it's faster than make. The real advantages are:
1) one build system for linux and windows (reducing from 3 to 2 build systems)
2) meson much simpler than autotools, scons, or (especially) cmake
3) recursive meson files, flat ninja file.

> 
> > Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much easier to understand
> > what the build system is doing.
> > 
> > What's different about using meson?
> > 
> > Well, apart from a faster builds and less magic in the build system? The
> > configure flags are different, it uses -D<opt>=<value> more like cmake
> > than the --enable or --with flags of autotools, although oddly it uses
> > --prefix and friends when calling meson, but not with mesonconf, there's
> > a bug opened on this. Meson also doesn't support in-tree builds at all;
> > all builds are done out of tree. It also doesn't provide a "make dist"
> > target, fortunately there's this awesome tool called git, and it
> > provides a "git archive" command that does much the same thing. Did I
> > mention it's fast?
> 
> Nothing against git archive, but you then would need to maintain .gitattributes
> in addition to the build system input files, correct? Right now the distribution
> rules are just in the Makefile.in files, making them more visible and less
> easily forgotten.

I've never had to use gitattributes for anything, are you thinking for setting
export-ignore and export-subst?

Dylan

> 
> > [...]
> 
> Cheers,
> Kai
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170321/e738c140/attachment.sig>