D support for the Meson build system

[H. S. Teoh via Digitalmars-d-announce]

On Mon, Apr 10, 2017 at 05:56:38PM +0000, Matthias Klumpp via Digitalmars-d-announce wrote:
> On Monday, 10 April 2017 at 15:27:25 UTC, Russel Winder wrote:
[...]
> > My thought for SCons was to delegate the package fetching to Dub as
> > a subprocess or write some Python to use the Dub API. I'm not clear
> > on that as yet, the issue is whether the Dub local source repo is
> > the right way forward – using Dub for preparing the compiled
> > artefact is likely not the right way forward for SCons. This would
> > then make it easy to do something for Rust/Cargo – except that SCons
> > doesn't really support Rust yet, and with Cargo are there any Rust
> > users not using Cargo.
> > 
> > Having said all this SCons stuff, if there was Meson support for
> > this "get the source from the Dub repository, compile it and make it
> > a dependency" I'd likely stay with Meson for my codes.
> 
> SCons is considered evil, last time I checked ^^ =>
> https://wiki.debian.org/UpstreamGuide#line867
> (unless it's used right, which seems to be hard) - I have no idea
> though on whether the issues with it were fixed, the entry on SCons
> hasn't been updated in a while.

I use SCons exclusively for my D projects, and haven't faced any major
problems.

I understand, however, that from a distro's POV, it can be annoying to
work with if you're not familiar with how to patch SConstruct scripts to
do what is needed.

It's true that unless upstream explicitly supports installation targets,
SCons won't do it for you. I do actually maintain a Debian package that
uses SCons (well, written by yours truly, so perhaps that's cheating),
and I did find that I have to write rules explicitly for supporting
installation targets just so it will work properly with Debian's
packaging scripts.

As for SONAME support (mentioned by the wiki), I'm not sure what the big
deal is... isn't it just a matter of passing the right linker flags to
the compile command? So either adding something to CFLAGS or LDFLAGS in
the construction environment should do the trick.

SCons refusing to pick up settings from the user's environment can be
annoying to distros, but in return for that, it gives you 100%
reproducible (incremental!) builds by default, whereas most Makefiles
require you to `make clean` just to be sure, to the point that it has
become accepted practice to always "build from clean" because otherwise
you just never know. Even Debian's packaging scripts have a `clean`
target because of this. But in an SCons-based package, the `clean`
target is a one-liner `scons -c`, since SCons knows what targets it has
produced and practically guarantees you're back to a clean slate.  Even
though that's actually unnecessary to produce a good build! (Ironically,
leaving the `clean` rule blank causes the packaging scripts to complain
because they notice stray files lying around, obviously a feature
written with a Makefile mindset because stray files are problematic in
Makefile-based projects, but hardly worth attention in an SCons-based
project!)


T

-- 
Curiosity kills the cat. Moral: don't be the cat.