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

Tue Mar 21 18:36:31 UTC 2017

Hey Dylan,
Dylan Baker wrote on 21.03.2017 18:34:
> Quoting Kai Wasserbäch (2017-03-21 09:50:52)
>> 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.

I hope the rest of the Mesa project would follow such a rule. Because if there's
something I absolutely hate about all those "new" build systems, then it's their
tendency to just download stuff and build/include that. This seems to have risen
with Node and now spread into Rust and other parts of the FLOSS eco-system.

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

Hm, I have written a lot of CMakeFiles.txt and so far I've always been rather
happy with them. Not sure what Piglit is doing though.

>> 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)

CMake or SCons would do the same AFAICS. Plus CMake seems to be used in the
Android eco-system already
(<https://developer.android.com/ndk/guides/cmake.html>), which might mean it
could be easier for the Android downstreams of Mesa? Not sure on that though.

> 2) meson much simpler than autotools, scons, or (especially) cmake

OTOH CMake gives you CTest/CDash
(<https://cmake.org/cmake/help/latest/manual/ctest.1.html>), CPack
(<https://cmake.org/cmake/help/latest/manual/cpack.1.html>), dependency
visualisation
(<https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html>) and
many other things for (basically) free. Maybe that warrants some complexity?

> 3) recursive meson files, flat ninja file.

IIRC you would also get the same with CMake if you target Ninja.

>>> 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?

Yep. AFAICT we have several files which aren't distributed if you do "make
dist". Those would need to be excluded from a tarball built with git archive as
well. AFAIK that's done through having .gitattributes files in the tree.

Anyway, I don't want to bikeshed here, so I'll be silent as long as any possible
future build system doesn't download stuff behind my back.

Thanks for your reply!

Cheers,
Kai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170321/471d2cdc/attachment.sig>