Here are some initial thoughts, based on my five-minute read of Russel's post and mesonbuild.com. I'm not a D user, but perhaps my user story can provide some perspective.
We switched from Make to SCons because of the complexity of our primarily GCC-based builds. There are a lot of "layers", and getting the dependencies correct was impossible - we would have been better off using a shell script, as at least everything would have gotten re-built. Now we strongly leverage SCons' ability to define custom builders which not only makes the build system cleaner (putting the messiness in just one location) but also to ensure that dependencies aren't missed. The fact that SConscript files are Python is a definite plus for us. We write implement custom builders in Python all the time. Going in, the projects were very monolithic; (external) "dependencies" were not used at all. As we converted things to SCons, we also took the time to pull out pieces of code into libraries. There were also places where snapshots of open-source libraries had been "dropped-in" and modified. Now those modifications are being managed as branches on local forks of the open-source Git repositories. Managing those external dependencies has been tricky. When I first saw the word "repository" and env.SourceCode() show up in SCons' documentation, I was very excited; "perhaps this will allow us to manage external code dependencies" I thought. Then I realized that only archaic systems like CVS and BitKeeper were supported, and the SourceCode() feature had been deprecated (emphasis mine): This function and its associate factory functions are deprecated. There is no replacement. The intended use was to keep a local tree in sync with an archive, but in actuality the function only causes the archive to be fetched on the first run. Synchronizing with the archive is best done **external to SCons**. We're currently using Git submodules but some developers struggle with them. Of course, we like to be able to develop/build/test all of these libraries independently. Some libraries have dependencies themselves, but we didn't want to git-submodule them into the higher-level library, because those dependencies could then get duplicated many times in the tree of a large project that is initialized with 'git submodule update --init --recursive'. So instead, we took the approach that libraries expect consuming projects to provide their dependencies; and for standalone development, libraries have a clone_deps.py script. It's not the most elegant - there is duplication between .gitmodules and clone_deps.py but it's generally manageable. With that said, the (external) dependency-handling mechanism in Meson looks intriguing. I'm not sure how well it would work in our use-case, but it definitely highlights an area that SCons has deliberately chosen to stay out of. Meson seems to consider this "subproject" concept as a first-class citizen of their build system (https://github.com/mesonbuild/meson/wiki/Subprojects). It would be great for us if SCons could support this concept a bit more. The other thing that Meson has going for it (IMHO) is that it is managed in Git, on GitHub, utilizing their standard issue tracker and pull requests, and building/testing on Travis and AppVeyor. (See previous discussions on that topic.) On Mon, Aug 29, 2016 at 4:10 AM, Russel Winder <rus...@winder.org.uk> wrote: > 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 > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > _______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev