D support for the Meson build system

[Matthias Klumpp via Digitalmars-d-announce]

On Monday, 10 April 2017 at 15:27:25 UTC, Russel Winder wrote:
> On Mon, 2017-04-10 at 12:41 +0000, Matthias Klumpp via 
> Digitalmars-d- announce wrote:
>> 
> […].
>> 
>> I am not buying the necessity of not-splitbuilding for 
>> optimizations yet. If that would be the case, how do 
>> optimizations work with projects using GCC/Clang where 
>> splitbuilding is the default and often only option (like Mesa, 
>> Linux, lots of scientific stuff).
>
> I am investigating this architecture because Chapel code cannot 
> really
> be compiled separately as far as I can see. cf. 
> http://chapel.cray.com/
>  Chapel is a PGAS language (like X10) for use with Big 
> Computation™ on
> serious computers and also any computer. I'm interested as a 
> way of
> connecting Python visualisation to computation that NumPy can't 
> really
> handle.

That's pretty cool! One way to do this with Meson is to spawn a 
shell script as custom target, but that obviously sucks. It might 
be worth reporting this as issue upstream, with a concrete 
usecase like this, the Meson maintainers will highly likely add 
support for it.
One could also always write a plugin as a last resort.

> It seems sensible therefore to offer this way of working for D 
> since whether there is actually any optimisation benefit or not 
> some people think there is and use it as a stick to beat you 
> with if it isn't there.
>
>> Having some level of dub integration is Meson would be neat
>> indeed - maybe one could make a small helper binary Meson can
>> call to fetch things from the dub registry.
>> I wonder though how that would jive with Meson's own
>> subprojects/wrap system. Probably worth investigating.
>
> 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.