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:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev