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

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

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

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.

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.

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.

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)

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.

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.

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 ... ?