Thread overview | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 21, 2014 What happened to GDMD | ||||
---|---|---|---|---|
| ||||
Hi, Whatever happened to revamped development on GDMD? I see that someone started work on re-writing it in D, but nothing has happened in 8 months. Is it still in development? Does it work? Can it be merged into the mainline project? Regards Iain |
February 21, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On Friday, 21 February 2014 at 16:20:35 UTC, Iain Buclaw wrote: > Hi, > > Whatever happened to revamped development on GDMD? > > I see that someone started work on re-writing it in D, but nothing has happened in 8 months. Is it still in development? Does it work? Can it be merged into the mainline project? > I've added a gdmd component in bugzilla http://bugzilla.gdcproject.org/describecomponents.cgi |
February 21, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On Fri, Feb 21, 2014 at 04:20:34PM +0000, Iain Buclaw wrote: > Hi, > > Whatever happened to revamped development on GDMD? > > I see that someone started work on re-writing it in D, but nothing has happened in 8 months. Is it still in development? Does it work? Can it be merged into the mainline project? [...] Sorry, I was working on it but got busy and never got back to it. You can get the last updated code here: https://github.com/quickfur/GDMD/tree/dport 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. T -- "I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information |
February 21, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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. |
February 21, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to eles | Am Fri, 21 Feb 2014 18:23:37 +0000 schrieb "eles" <eles@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. |
February 21, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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@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. |
February 22, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On 21/02/2014 17:20, Iain Buclaw wrote:
> Whatever happened to revamped development on GDMD?
For reference ... I still just install the old perl script manually :o)
|
February 22, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
On 21/02/2014 20:50, H. S. Teoh wrote: > On Fri, Feb 21, 2014 at 08:02:45PM +0100, Johannes Pfau wrote: >> 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 ??!! What was it using from it? A typical dmd.conf would be e.g. [Environment] DFLAGS=-I/opt/dmd/include/d2 -L-L/opt/dmd/lib -L--no-warn-search-mismatch so it's difficult to see what any other compiler/compiler wrapper could get from that that would be anything other than wrong. Are there options I've previously been unaware of? > 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? I don't see why there's a need for any .conf file for gdmd. If each gdmd install is associated with a unique gdc install (which I think is the correct choice) then all it needs to do is convert one set of flags to another. I suppose we could have a .conf file that allows some customization of how that is done (e.g. that allows you to customize whether -O means -O3 or -O2 or some other set of optimizations), but it seems overkill. I can't see any way in which a "fallback to parsing dmd.conf" could have any positive consequences given what dmd.conf contains. |
February 22, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
On 22 February 2014 07:33, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 21/02/2014 20:50, H. S. Teoh wrote:
>>
>> On Fri, Feb 21, 2014 at 08:02:45PM +0100, Johannes Pfau wrote:
>>>
>>> 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
>
>
> ??!!
>
> What was it using from it? A typical dmd.conf would be e.g.
>
> [Environment]
> DFLAGS=-I/opt/dmd/include/d2 -L-L/opt/dmd/lib -L--no-warn-search-mismatch
>
IIRC, it was parse that and push it into the Perl ENV.
$ENV[$VAR] = $VAL
Then immediately after reading the ini file, push $ENV[DFLAGS] into the $ARGV list.
Then it's parse all arguments as if they were dmd command options.
Admittedly, you wouldn't use dmd's dmd.conf for gdmd. ;)
Regards
Iain.
|
February 23, 2014 Re: What happened to GDMD | ||||
---|---|---|---|---|
| ||||
On 21/02/2014 18:09, 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.
Do you have a todo list ... ?
|
Copyright © 1999-2021 by the D Language Foundation