[scons-users] Evolving the D tool for SCons

[H. S. Teoh]

On Mon, Mar 19, 2012 at 05:47:11PM +0000, Russel Winder wrote:
> On Mon, 2012-03-19 at 07:55 -0700, H. S. Teoh wrote:
> [...]
> > Thank you!!! The current D support in SCons is very spotty; I'm
> > finding myself having to redefine DCOM and LINKCOM in order to make
> > things work.  I actually wanted to make some changes to D support in
> > SCons for a while now, but just never had to time to get around to
> > it. Thanks for picking this up!
> 
> I bet that having to change DCOM and LINKCOM is a consequence of the
> current dmd tool only really supporting GDC when it was D v1.

That's another problem: D1 and D2 have some significant differences, but
all D code use the .d extension regardless of the language version. So
this makes inferring language versions tricky if the SCons plugin ever
needs to distinguish between them.


> Although the dmd tool is part of SCons core, development of the tool
> happens via an add in tool in the form of the package in the Mercurial
> repository at  https://bitbucket.org/russel/scons_dmd_new Doing this
> means that people can participate in helping develop the tool by using
> the latest experimental version using a standard release SCons, i.e.
> without having to fork the SCons distribution.

Cool.


> > DMD, GDC, and LDC are alternative compilers for D. Granted, they all
> > use the same frontend that comes from DMD, but they are independent
> > of each other and generally you'd pick one of them and stick to it
> > in a single project.
> 
> So the crucial question is whether to continue with a single SCons
> tool dmd which then has to sort out whether to use DMD, GDC or LDC, or
> whether to have separate tools dmd, gdc, ldc all of which share some
> common material.  Both of these are viable solutions, the question is
> which better fits "real D projects using SCons" work practices.

I can't speak for all D projects, and I don't know how many D projects
actually use SCons to begin with, but due to my work on some druntime
stuff I sometimes want to compile the same code with different
compilers, or different versions of the same compiler, to check for
differences. So it would be nice if something like this can be supported
in a clean way (e.g., modify an Environment variable to indicate which
compiler to use).

But I don't think this is typical usage. Generally you'd stick to a
single compiler for each project.


> > > The current SCons tool emphasises DMD, even to that being the
> > > name, and has only partial support for GDC, and none really for
> > > LDC.
> > 
> > I use GDC, and like I said, I find myself having to redefine LINKCOM
> > and DCOM in order to make things work.
> 
> This is not good.  Mayhap put an issue up at
> https://bitbucket.org/russel/scons_dmd_new/issues along with some data
> to be able to make a unit and/.or system test?

The main problem is that DMD and GDC have different command-line syntax.
GDC uses the usual GCC options, plus a few D-specific ones transferred
over from DMD, but to avoid conflicts with GCC-specific options, GDC's
D-specific options are all prefixed with 'f'. So whereas in dmd you'd
write:

	dmd -unittest source.d

in GDC, you'd have to write:

	gdc -funittest source.d

Because of this, the SCons plugin needs to know which compiler it's
dealing with, so that it can pass in the correct option syntax on the
command-line.


> > It would be *really* nice if there was a way to tell SCons which
> > compiler to use and have it automatically set up Environment
> > variables to work for the selected compiler. Currently, I'm working
> > on both my own projects (GDC) and on some druntime/phobos code
> > (DMD), so being able to select which compiler to use is very
> > important for me.
> 
> This should happen automatically.  it does for C, C++ and Fortran, so
> it should for D.  The right approach really depends on whether people
> want to say "this is a D project, go away of get a D toolchain in
> place" or whether they want to say "I want the (DMD|GDC|LDC) toolchain
> and raise an error if it is not in place".  Or put another way,
> repeating a comment made earlier, should there be one D tool or many D
> tools.  Fortran, C and C++ have a mixed situation, you can specify a
> particular toolchain or ask the system to deduce the best one -- bet
> here is determined via a fixed predetermined priority on a per
> platform basis.

The way I envision how it should work is that you simply specify a path
to the compiler, say:

	env = Environment(
		DCOMPILER = '/usr/bin/gdc-4.6',
		...
	)

then the SCons plugin will automatically detect which compiler it is,
and select the correct command-line syntax to invoke it with.

If DCOMPILER is not specified, then DMD should be the default, unless it
can't be found, in which case either GDC or LDC should be searched for.

Now, another complication is multi-language projects. D supports
cross-linking with C (and a subset of C++, though support is weak on
that front). Generally, it's a bad idea to mix gcc with dmd or gdc with
dmc in such projects; on some platforms (e.g. Windows) this simply
doesn't work. There's also the issue of which linker should be used. On
Linux, this is relatively straightforward (IIRC, dmd supports native
Linux linkers), but on Windows there are some compatibility problems
between dmd and Windows native linkers.


> > I'm using Debian/Linux (unstable) on an AMD 64-bit machine. I'm
> > willing to test stuff. But I don't have a windows development
> > environment, unfortunately. :-(
> 
> Sounds very like my set up. It would be good to have someone other
> than me testing on this set up though in case I write in me specific
> things.

Sure.


> Are you in a position to use the tool from BitBucket rather than the
> standard tool?
[...]

As long as I can easily swap the bitbucket version in/out with the
SCons-shipped version, it should be no problem. :-)

If not, I can always setup a chroot to experiment with.


T

-- 
Shin: (n.) A device for finding furniture in the dark.