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.
