Re: D support, not sure what to do

Russel Winder <[email protected]> Sat, 08 Apr 2017 14:47:45 +0100
Newsgroups	gmane.comp.programming.tools.scons.devel
Message-ID	<[email protected]>
On Sat, 2017-04-08 at 15:01 +0200, Dirk Bächle wrote:
> Hi Russel, hi Jean-Baptiste,
> 
> 
> thanks a lot for starting and chiming in on this topic, which I think
> is 
> an important one. When I read Russel's other (opinionated) post
> about 
> how D is likely to gain more ground than Rust/Python in the future,
> I 
> asked myself: What can we possibly do to support this? How can we be 
> ready for this stream of development if it should really happen in, 
> let's say, 2019?

Much of my writing is opinionated, I have now tried to mark where that
is the case. :-)

> 
> So I'm all ears for trying to get better support for D into the
> SCons 
> core. For me the main question, referring to your subject of "...,
> not 
> sure what to do", is: What exactly would have to be done to make
> SCons 
> the canonical choice as build system for D?

Dub is for the short and medium term always going to be the default
choice for people to build D code. Like Cargo it has its good, and
indeed excellent points. However some choices Dub makes, which Cargo
makes differently, mean that Cargo works and Dub has some serious
problems. 
> 
> Can someone (we together) compile a list of things that would have
> to 
> get implemented and improved? Something along the lines of:
> 
> 
> - We need recursive Globbing. (Full support of Ant-like syntax)
> 
> - We need to be able to handle required Libraries as leaf nodes in
> the 
> dependency tree, even if they reside in a remote
> repository/artifactory.
> 
> - We need to be able to cache the contents of those libraries
> locally 
> (in case of being offline).
> 

We need to be able to do build by individual file compilation and then
explicit linking *and* we need to support all source at once compile
and link in one go.

We need to support getting source from a central repository and
compiling that ready for being linked to during project compilation.

We need easy management of debug, optimiseddebug, and release
configurations.

We need to pinch lots of nice ideas from Meson! Meson takes a lot of
ideas from SCons and Waf about specification using a nice DSL, and the
configure/build split idea from Waf and CMake. Meson is a Ninja
configuration system as CMake is a Make or Ninja configuration system.
The big win for Waf and SCons over Meson and CMake in my opinion is
that the DSL is Python code and not a DSL that is parsed as with Meson
and CMake.

> (I'd like to continue this list but my knowledge of D is obviously 
> restricted...so feel free to add "- We need more SCons core devs to
> be 
> proficient in D development." to the list above ;) )

We need more people who know and use D actively involved. :-)

Ditto Fortran and C++17 I guess.

C++20 will likely have modules, they did not get into C++17. So SCons
is going to have to be able to deal with that. i.e. the whole #include
system will be going. But eventually, this is just an early warning.

> 
> Then we should have a look at this list, and decide which points are 
> technically feasible and "in line" with SCons' basic design
> principles. 
> We can probably also identify a number of features that are not only 
> helpful for D...but other languages/toolchains as well. Those should
> get 
> the highest priority perhaps...but I also believe that any kind of 
> development in the core sources, even if strictly D-oriented, is
> good 
> for the project.

My feeling is that the hardest problem is going to be getting and
building dependencies, the rest just requires people writing test cases
and fixing the code that they break. The "all source at once" is I
think just a question of creating a ProgramAllAtOnce to augment the
Program. It just creates a single executable node with no object nodes
in the tree. Shouldn't be a problem.

I see no reason not to use Dub to get the source. Or if we do not want
to make use of an external program use the Dub API directly from newly
written code. I prefer the latter myself, but I know some packages
(such as Unit-Threaded) seem to require the Dub executable – I haven't
sorted out why yet.

I suspect the biggest hurdle is going to be that there are three D
compilers leading to a similar problem as the C and C++ compiler
selection. 

In the end though it is down to effort and maintaining non-zero
progress.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[email protected]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [email protected]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
signature.asc (application/pgp-signature, 833 B)