Am Fri, 21 Feb 2014 18:23:37 +0000 schrieb "eles" <e...@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.
