[Scons-dev] D support, not sure what to do

[Russel Winder]

On Fri, 2017-04-07 at 21:51 +0200, Jean-Baptiste Lab wrote:
> Hi list,
> 
> This is mainly directed at Russell, but I hope he and I are not the
> only one willing to build D code with SCons.

There are others out there. Dub is not universally liked as a build
tool, there are SCons, Meson and CMake likers.

> I have a pet project of mine[1], mainly to scratch 2 itches:
> - learning D
> - helping me with managing my time
> 
> I started using dub as the build system for it but started quickly
> spending a lot of time fighting with it to get it to do things I
> expected it to be able to do (installing stuff, integrating with
> system dependencies, handling translations, etc) instead of actually
> coding the thing. I even submitted patches.
> Eventually, I acknowledge that dub  wasn't either quite there yet or
> simply that I was using the wrong wrench to nail that thing (?).
> Anyway, what I ended up doing (which I must admit is pretty much what
> I always end up doing) was going with SCons which doesn't quite do
> what I want, but most of the time is halfway there because of its
> flexibility.

I have had to finally allow myself to be drawn into using Dub. It has
at least one fundamental flaw when it comes to building downloaded
packages, but if you restrict to "dub fetch" for just getting the
source code, it is OK.

>  I implemented a few wrappers and utilities around the D builders in
> SCons [2] (unit test builder,  ddoc builder, etc) and am now up to a
> point where I think they're worth sharing, at least with you guys.

I was (but then had to switch to CMake and Meson which already have
this) trying to create a GNUInstall toolkit for doing an install in an
XDG compliant way. As far as I know there is no official SCons tool for
this.

In fact is this a tool or just a package for import into a SConstruct
or SConscript file? Should we be making a distinction and supporting
both equally?

I think SCons needs a resurgence of activity making it trivial to get
extra support tooling in place. The infrastructure is there, it just
needs a layer on top to make it a trivial UX. 

Clearly using Git, Mercurial, or Bazaar (though Git has become the only
one these days) allows people to have their own repositories for tools
and packages. This part of the infrastructure now just works, but you
have to use it correctly. I think we need to ramp up centralising
vetted and tested tools and support packages to the central repository,
and then have a command to install and uninstall tools and support
packages from a project, user, or for the whole machine.

> I am willing to help with D support in SCons as I hope this would
> attract more people to both D and SCons (the best combo if you ask
> me), but I don't have much time, a situation many of you I'm sure are
> familiar with😉

Whilst Python is likely the best solution to write SCons support stuff
in, maybe we could do it in D. :-)

> I'm writing this on my phone while waiting for my kids to fall
> asleep, I'll try to elaborate a bit more tomorrow....
> 
> [1] https://bitbucket.org/jbl/ttracker
> [2] https://bitbucket.org/jbl/site_scons
> 
[…]
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170408/630a0679/attachment.pgp>