From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Kai_Wasserb=c3=a4ch?= Subject: Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson Date: Tue, 21 Mar 2017 19:36:31 +0100 Message-ID: <793fefc2-bdbf-dbf7-e4a1-1f7dc12cf940@dev.carbon-project.org> References: <3eb98e88-f495-b7cf-aea9-21be6793793a@dev.carbon-project.org> <149011764799.7993.7028908780598864763@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1341984170==" Return-path: In-Reply-To: <149011764799.7993.7028908780598864763@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org, mesa-dev@lists.freedesktop.org Cc: Dylan Baker List-Id: dri-devel@lists.freedesktop.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1341984170== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tdVj12mfwsj7Ct2x9kQeAsaj4f9kargT5" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tdVj12mfwsj7Ct2x9kQeAsaj4f9kargT5 Content-Type: multipart/mixed; boundary="mBRdGep9a5w7wTwAvXsxUBUowaOtWs9L1"; protected-headers="v1" From: =?UTF-8?Q?Kai_Wasserb=c3=a4ch?= To: dri-devel@lists.freedesktop.org, mesa-dev@lists.freedesktop.org Cc: Dylan Baker Message-ID: <793fefc2-bdbf-dbf7-e4a1-1f7dc12cf940@dev.carbon-project.org> Subject: Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson References: <3eb98e88-f495-b7cf-aea9-21be6793793a@dev.carbon-project.org> <149011764799.7993.7028908780598864763@localhost.localdomain> In-Reply-To: <149011764799.7993.7028908780598864763@localhost.localdomain> --mBRdGep9a5w7wTwAvXsxUBUowaOtWs9L1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hey Dylan, Dylan Baker wrote on 21.03.2017 18:34: > Quoting Kai Wasserb=C3=A4ch (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 wa= y deeper >> involved with Mesa and their opinion is what matters in the end. Anywa= y, 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 >> >> but that seems to imply a silent fallback to downloading stuff. I woul= d 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 "--distributi= on-build" >> flag? If there isn't I would rather see a switch to CMake (as others h= ave >> pointed out in this thread: many projects in the vicinity of Mesa alre= ady use >> CMake), but I get that there's a lot of hate for CMake (even though th= e Meson >> syntax looks a lot like CMake, so I'm not really sure why?) and such a= switch >> would be unlikely. >=20 > 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 w= rap is > that we would have something like this: >=20 > if host_machine.system() !=3D 'windows' > dep_zlib =3D dependency('zlib', version : '>1.0.0') > else > subproj_zlib =3D subproject('zlib') > dep_zlib =3D subproj_zlib.get_variable('zlib_dep') > endif >=20 > Which would make the dependency a hard requirement for non-windows syst= em (i.e. > the configure fails if zlib isn't found *except* on windows), and windo= ws could > fall back to wraps. >=20 > 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 t= heir own > choice on how to handle dependencies (I have no idea what their develop= ment > 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 pa= ckage > management solutions without the need to automatically download sources= =2E 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 hav= e risen with Node and now spread into Rust and other parts of the FLOSS eco-syste= m. > 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 thing= s I'll > reiterate that impressed me the most about meson is that it's syntax is= simple, > not Turring-complete, and opinionated. >=20 > In fact, piglit is the best reason not not use cmake I can come up with= =2E 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 cmak= e 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 abou= t 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 lang= uage with > enough warts to make bash look cuddly. Hm, I have written a lot of CMakeFiles.txt and so far I've always been ra= ther 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 bas= e >>> 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 t= he >>> 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 >> , can use/ge= nerate for >> ninja too. >=20 > 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 s= ystems) CMake or SCons would do the same AFAICS. Plus CMake seems to be used in t= he Android eco-system already (), which might mean= it could be easier for the Android downstreams of Mesa? Not sure on that tho= ugh. > 2) meson much simpler than autotools, scons, or (especially) cmake OTOH CMake gives you CTest/CDash (), CPack (), dependency visualisation () = and many other things for (basically) free. Maybe that warrants some complexi= ty? > 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=3D more like cm= ake >>> than the --enable or --with flags of autotools, although oddly it use= s >>> --prefix and friends when calling meson, but not with mesonconf, ther= e's >>> a bug opened on this. Meson also doesn't support in-tree builds at al= l; >>> 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 .gita= ttributes >> in addition to the build system input files, correct? Right now the di= stribution >> rules are just in the Makefile.in files, making them more visible and = less >> easily forgotten. >=20 > 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 "mak= e dist". Those would need to be excluded from a tarball built with git arch= ive 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 p= ossible future build system doesn't download stuff behind my back. Thanks for your reply! Cheers, Kai --mBRdGep9a5w7wTwAvXsxUBUowaOtWs9L1-- --tdVj12mfwsj7Ct2x9kQeAsaj4f9kargT5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEBgCWzvPI5zPlthWHownXbOHeWdIFAljRcq8ACgkQownXbOHe WdK3WQwAtz3nw2tBgiYj/z/0ctdZM6UCVpRC8as7DRvmfF1AsFUbKWdgBFYp/uGE kVr14aRD/QR8cgFfQdWEESse3EVkHBpVDj3F3AmyTtKm0M7TEmT/lZP8kklYBHtF dyeIV10LecFdUgbtNOQ3zNKC2kK4nbslmVtdFhhxgq1aHFI9bDRGAXR+XAiv2lFu zOXUReVjYlwW4H3TqWgvbuhN4RzPDXn9OpKOaVIvSU98zzs9OpsWucBaSAOLGBIt IoQ5ca4FdwJHPRFzOj2SNqYcgUHPT/W3Q1k6dlxr6xfVXt2N2JqHDpVijdfXUisa DNcP129rd3eItQurJ6kDOU/GDoKCSxxANdp48kUHhnBl/eBmuGjhiZ4t+jTPT7Zm sS17nnra7S86pjHrvqrZiVxq55OaMyzMSpbrB52PDhtITy24YfVn2vYP328t+YtJ 6Xfxu9V7Tp1m4m5U3ZgpqdL7wzPMI7dNsP+r9cqoCw46BzLXYsB0cXKioEL+T/nj YcA6ZV0A =bPY4 -----END PGP SIGNATURE----- --tdVj12mfwsj7Ct2x9kQeAsaj4f9kargT5-- --===============1341984170== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1341984170==--