Installing things – SCons vs Meson

[russel]

As requested by @bdbaddog a brief analysis of why Meson is superior to SCons (as at 2019-08-28) for installation.

Meson is an opinionated Ninja build generator, whereas SCons is a generalised replacement for Make. In the same way that Autotools turned Make into a less general but more useful system, Waf tried to turn SCons from a less general, more Autotools like, system. Meson builds on SCons, Waf, and others to create a replacement for Autotools. Clearly CMake is another player in the game with similar goals and arguably more traction.

The Meson language is a domain specific language very similar to Python, but it is not Python – though it allows Python code to be executed if need be. SCons (and Waf) are frameworks built on Python.

Meson assumes out of tree builds, very much like CMake and Waf; Autotools and SCons allow for out of tree builds, but make it quite complicated in comparison.

SCons has installation builders, but they have no model of the platform being executed on – this means all destinations have to be specified, and any platform variation programmed in the build. Meson (and Waf before it) chose to have installation models for the platform of execution. So on Windows and macOS there are conventions for where things get installed, on UNIX and Linux there are the XDG rules defining where things get installed.

With Meson each builder allows for a Boolean field as to whether the build product is installable. If it is installable and "ninja install" is executed, the build product will be installed to the natural installation location for that type of build product. This can be overridden as desired, specifying the exact destination, but this is rarely used as the platform installation models are invariably correct.

For example here is the builder statement for creating an executable form some D sources:

executable(
    'gfontbrowser',
    sources,
    dependencies: dependencies,
    include_directories: includes,
    d_args: d_args,
    link_args: link_args,
    install: true,
)

sources, dependencies, includes, d_args, and link_args are variables defined beforehand. The install property is set to true. So this build product is installed to the right location on "ninja install" – or uninstalled on "ninja uninstall".

Meson is, like Waf and CMake, a system where you must create the build system before building things. I chose to have a BuildArea directory totally separated from the source. In the GFontBrowser subdirectory, executing:

meson --prefix=$HOME/Built ~/Repositories/Git/Master/Public/GFontBrowser

creates the Ninja build. By setting the prefix, just as with Autotools, Waf, CMake, the Ninja build will install everything to the prefix directory. On Linux the XDG convention is assumed and so the gfrontbrowser executable once built will get installed to $HOME/Built/bin.

As far as I am aware SCons currently has no tooling to allow for these platform specific installation models.

I began trying to do something within SCons but when Meson started getting traction, I gave up and switched to Meson.

PS There is a whole similar issue with pkg-config, SCons support for it is vastly inferior to that of Meson – again due to SCons trying to be generalised whilst Meson seeks to have conventions built in.

[chasinglogic]

For this exact problem MongoDB has been working on the AutoInstall tool that we hope to get upstreamed.

[russel]

My PkgConfig experimentation is at https://github.com/russel/SCons_PkgConfig I haven't made the XDG experimentation public, I should do this.

[gour]

I began trying to do something within SCons but when Meson started getting traction, I gave up and switched to Meson.

Altogether?

[russel]

I began trying to do something within SCons but when Meson started getting traction, I gave up and switched to Meson.

Altogether?

More or less, yes, but not totally.

[gour]

More or less, yes, but not totally.

Thank you for reply.

[mwichmann]

I've moved this to a "discussion" since it doesn't document any specific issue to fix.