D, SCons and Meson
Russel Winder <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.devel |
|---|---|
| Message-ID | <[email protected]> |
In case you hadn't heard, Meson is the "new kid in town" on the build front. It is a Python front end to a Ninja back end. It is clearly in the SCons and Waf tradition (with some CMake) but very much a Ninja backend replacement to Autotools in it's entirety. Meson will make Waf (and CMake?) irrelevant not for any technical reasons, but because the GNOME/GUADEC type folks are seeing Meson as the replacement for their Autotools build – for those that do not think Autotools is all they will ever need. i.e. it is getting rapid traction. Debian maintainers are already seeing it as a main build player where, sadly, SCons never really made it. Waf was rejected since it maintained the position of being in the project not in the distribution. This is a really interesting tension: Gradle has driven the "in the project" idea to being the norm in the JDK world (and also some of the C++ world), but this is not acceptable with many contexts including Debian and Fedora. Why am I emailing this at all? Well it relates to D-related stuff. I had been trying to make SCons the D build of choice for those not using Dub. However Meson has come charging in and has taken pole position in the Debian and likely Fedora communities as the build of choice for D- related packaging. Yes SCons could still be used, but I suspect Meson is going to win this game. I am still intending to create a dependency handling system in SCons for D to communicate with the Dub repository for downloads to get and build (using the Dub default locations), but instead of being primary, this will now be a port of the Meson version. Unless I have missed something (*), SCons hasn't picked up the ideas of Gradle, Maven, Cargo, Dub, Herd, Go, Pip/PyPI, Ruby Gems, etc. that there are repositories of artefacts (compiled in the JDK world, source in the native code and interpreter worlds), it is still about a pre- 2000 view of project. Neither have CMake or Waf really, but it seems Meson is going this direction. A generalized Cargo/Dub/Go style mechanism of getting source code dependencies from a repository as a calculated dependency. This is a Big Win™ in modern software development – except for big companies that have unitary proprietary codebases. SCons remains the One True Way™ for XeLaTeX builds obviously, but I am likely to be doing less and less SCons stuff due to the Debian and Fedora packaging focus and the rise of Meson (**). (*) Entirely possible, my uses of SCons are really rather straightforward. (**) I am convinced Meson is not a flash in the pan that goes away such as Rant, and Rake really. The traction it is getting with projects like GStreamer seem to indicate it is here to stay, that CMake is the loser and that Autotools will fade away gradually. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder _______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
signature.asc
(application/pgp-signature, 801 B)
-----BEGIN PGP SIGNATURE----- iQIcBAABCAAGBQJXw+39AAoJENS91dLOzae4/CsP/iz49Wqr1Li/6GKVfJursfLc ql+dxvUno7Xz7n49AXtd7fuCTd70iecxDzl32LmeTxB23PrBehBylulmhqW0pHFR yAXa2qwMGPTtCjrXRMgQcONQI5bnz7z/M0M8xWM3Pn/AvG/s0R3gyycYu1TUbE5b NAeDUo4s4oC8vHLOE+/B4pND2q0xNdp15tHsyC8kVjsWLg/BvX8hyoZAGUHXyxIm w4RV8eH+2P4Ey5DUfBQW5LvdY7AqKUKTEMOC0DEKYTxNIGzhGj1CU5SR5tGM9mpw ugXqVhIX3QfqPP5B2DnsF8Nksyxlch9M/ZIKIE5EYT3zECBPTQr6l/php8KEX5Bl mDoyM2cIDjiYetK1iQtxSIcNw18sRo+PjMlZgA9Q/K0NRivq5Mp0joCMGLzodYIR 43q7fm/B7CQhAq7T9hlv32xFvHyamxhCxRgHVooRvae++eUYDvcnEEgSxKE9GeRi IKwlNnBznTm9IsLeE43UW4ONv+EeFdTYoUzDl747rd7jA58NHyUPi/iLzI6p4/Yn obo07Ii1V1J2OmxBjf2exn/vcZ3hd1GvhxfJ3X1AiQXCWNz6V2+gkXrk7EX/wvLZ Uw3R2RSvb1MemFFiZ16VS9zcge47MX5JtilceNtFY459t1+qO3KxyLW9WKNERq3w 0f5x5k267Qd76gsAOZFp =pUxN -----END PGP SIGNATURE-----