www.digitalmars.com         C & C++   DMDScript  

D.gnu - What happened to GDMD

reply "Iain Buclaw" <ibuclaw gdcproject.org> writes:
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
Feb 21 2014
next sibling parent "Iain Buclaw" <ibuclaw gdcproject.org> writes:
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
Feb 21 2014
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Feb 21 2014
parent reply "eles" <eles eles.com> writes:
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.
Feb 21 2014
parent reply Johannes Pfau <nospam example.com> writes:
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.
Feb 21 2014
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Feb 21 2014
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Feb 21 2014
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Feb 22 2014
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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)
Feb 21 2014
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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 ... ?
Feb 23 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 Feb 2014 09:30, "Joseph Rushton Wakeling" <
joseph.wakeling webdrake.net> wrote:
 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 ... ?
If so, put it on the wiki or raise separate bugs for each in bugzilla to allow us to keep track what needs implementing.
Feb 23 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 23, 2014 at 09:38:09AM +0000, Iain Buclaw wrote:
 On 23 Feb 2014 09:30, "Joseph Rushton Wakeling" <
 joseph.wakeling webdrake.net> wrote:
 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 ... ?
Unfortunately, no. But basically, most of the remaining task is just to implement DMD option. The basic compile-and-link step is already working, but ddoc isn't handled yet, along with a whole bunch of dmd options that will probably require changing the way the compiling and linking is done, etc.. Just try it out yourself to see what works / doesn't work, and you'll see. :) The parseArgs function is where you'd start looking, to see what has / hasn't been implemented as far as options go.
 If so, put it on the wiki or raise separate bugs for each in bugzilla
 to allow us to keep track what needs implementing.
Should we be putting tickets in bugzilla when the dport branch isn't even merged yet? T -- Help a man when he is in trouble and he will remember you when he is in trouble again.
Feb 27 2014
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 27 February 2014 19:10, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Sun, Feb 23, 2014 at 09:38:09AM +0000, Iain Buclaw wrote:
 On 23 Feb 2014 09:30, "Joseph Rushton Wakeling" <
 joseph.wakeling webdrake.net> wrote:
 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 ... ?
Unfortunately, no. But basically, most of the remaining task is just to implement DMD option. The basic compile-and-link step is already working, but ddoc isn't handled yet, along with a whole bunch of dmd options that will probably require changing the way the compiling and linking is done, etc.. Just try it out yourself to see what works / doesn't work, and you'll see. :) The parseArgs function is where you'd start looking, to see what has / hasn't been implemented as far as options go.
 If so, put it on the wiki or raise separate bugs for each in bugzilla
 to allow us to keep track what needs implementing.
Should we be putting tickets in bugzilla when the dport branch isn't even merged yet?
Yes, you can use these as project tasks/goals to remind anyone what is left to do. You could also create a separate branch as a staging area to merge the current changes in. :)
Feb 27 2014