What happened to GDMD

[Johannes Pfau]

Am Fri, 21 Feb 2014 18:23:37 +0000
schrieb "eles" <eles at eles.com>:

> On Friday, 21 February 2014 at 17:53:15 UTC, H. S. Teoh wrote:
> > On Fri, Feb 21, 2014 at 04:20:34PM +0000, Iain Buclaw wrote:
> 
> > It's not quite ready to replace the current script yet, as a 
> > number of
> > dmd options are still not handled (or not completely handled) 
> > yet. It
> > would be nice if others could contribute to the code; I've been 
> > very
> > busy with other things recently and haven't been giving it the 
> > TLC that
> > it needs.
> 
> Hey, me too I did contribute a bit to that and I would be glad to
> contribute a bit more, but I do not feel like I could do it
> without a help hand. At least sorting issues that still need to
> be solved and I will try to attack one at a time.

The code looks nice so far.

Some comments:

We now have http://dlang.org/phobos/std_file.html#thisExePath
which could replace findScriptPath.


We'd also have to decide how we want to ship gdmd:

1: Ship one copy of gdmd with every gdc like we used to do.
   Then we can use
   thisExePath.dirName()/thisExePath.baseName().replace("gdmd", "gdc")
   as path for gdc. This has some benefits (arm-linux-gdmd always calls
   the correct gdc)
2: We ship gdmd as a extra tool and provide some way to select the used
   gdc, "gdmd --use-gdc=arm-linux-gdc"
   "gdmd --use-gdc /usr/bin/arm-linux-gdc"
3: A combination of 1/2: We autodetect the path as in 1, but allow
   changing the compiler with a cmd flag as in 2.

I'd prefer 1/3.

Did the old gdmd also parse dmd.conf? I'm not sure if this is
necessary. Parsing /etc/dmd.conf is even problematic as it might contain
library paths with incompatible libraries. We could use a gdmd.conf but
I don't think that's high priority for gdmd? So if that stuff is
already finished - great. If it's not, I wouldn't worry about that.