D.gnu - What happened to GDMD
- Iain Buclaw (7/7) Feb 21 2014 Hi,
- Iain Buclaw (3/8) Feb 21 2014 I've added a gdmd component in bugzilla
- H. S. Teoh (13/20) Feb 21 2014 [...]
- eles (5/15) Feb 21 2014 Hey, me too I did contribute a bit to that and I would be glad to
- Johannes Pfau (23/40) Feb 21 2014 The code looks nice so far.
- H. S. Teoh (11/52) Feb 21 2014 Agreed.
- Joseph Rushton Wakeling (16/27) Feb 21 2014 ??!!
- Iain Buclaw (10/27) Feb 22 2014 IIRC, it was parse that and push it into the Perl ENV.
- Joseph Rushton Wakeling (2/3) Feb 21 2014 For reference ... I still just install the old perl script manually :o)
- Joseph Rushton Wakeling (2/4) Feb 23 2014 Do you have a todo list ... ?
- Iain Buclaw (4/9) Feb 23 2014 If so, put it on the wiki or raise separate bugs for each in bugzilla to
- H. S. Teoh (15/28) Feb 27 2014 Unfortunately, no. But basically, most of the remaining task is just to
- Iain Buclaw (4/29) Feb 27 2014 Yes, you can use these as project tasks/goals to remind anyone what is
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
"Iain Buclaw" <ibuclaw gdcproject.org> 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
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
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
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: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.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
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>:Good idea.On Friday, 21 February 2014 at 17:53:15 UTC, H. S. Teoh wrote:The code looks nice so far. Some comments: We now have http://dlang.org/phobos/std_file.html#thisExePath which could replace findScriptPath.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.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
On 21/02/2014 20:50, H. S. Teoh wrote:On Fri, Feb 21, 2014 at 08:02:45PM +0100, Johannes Pfau wrote:??!! 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?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.confbut 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
On 22 February 2014 07:33, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:On 21/02/2014 20:50, H. S. Teoh wrote: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.On Fri, Feb 21, 2014 at 08:02:45PM +0100, Johannes Pfau wrote:??!! 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-mismatchDid 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
Feb 22 2014
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
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
On 23 Feb 2014 09:30, "Joseph Rushton Wakeling" < joseph.wakeling webdrake.net> wrote:On 21/02/2014 18:09, H. S. Teoh wrote:If so, put it on the wiki or raise separate bugs for each in bugzilla to allow us to keep track what needs implementing.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
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: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.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.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
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: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. :)On 23 Feb 2014 09:30, "Joseph Rushton Wakeling" < joseph.wakeling webdrake.net> wrote: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.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.Should we be putting tickets in bugzilla when the dport branch isn't even merged yet?
Feb 27 2014