[Scons-dev] D, SCons and Meson

Mon Aug 29 07:33:34 EDT 2016

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 <russel at 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.winder at ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>