What happened to GDMD
H. S. Teoh
hsteoh at quickfur.ath.cx
Fri Feb 21 11:50:52 PST 2014
On Fri, Feb 21, 2014 at 08:02:45PM +0100, Johannes Pfau wrote:
> 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:
> > > 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.
Good idea.
> 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.
Agreed.
> 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.
The old gdmd did parse dmd.conf, but arguably it should be parsing
gdmd.conf instead. I suppose the idea is that gdmd should be a drop-in
replacement for dmd, so if no gdmd.conf is found, it should probably
fall back to parsing dmd.conf? Not sure what to do with the conflicting
libraries problem, though.
T
--
The richest man is not he who has the most, but he who needs the least.
More information about the D.gnu
mailing list