www.digitalmars.com         C & C++   DMDScript  

D.gnu - gcc 4.8.1 made it to Debian Sid

reply "eles" <eles eles.com> writes:
and into Ubuntu Saucy.

Is the corresponding gdc-4.8.1 package 
(http://packages.debian.org/sid/gdc-4.8) improved with respect to 
the previous gdc-4.8? The changelog of gdc-4.8.1 only show info 
about the gcc.

BTW, why the gdc-4.8 git branch is no longer updated? We should 
compile master only against gcc-4.9?

Thanks.
Jun 05 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 06/05/2013 05:44 PM, eles wrote:

 BTW, why the gdc-4.8 git branch is no longer updated? We should compile master
 only against gcc-4.9?


master currently compiles against gcc-4.8.1, at least on my system :-)
Jun 05 2013
parent reply "eles" <eles eles.com> writes:
On Wednesday, 5 June 2013 at 15:55:51 UTC, Joseph Rushton 
Wakeling wrote:

 On 06/05/2013 05:44 PM, eles wrote:
 master currently compiles against gcc-4.8.1, at least on my 
 system :-)


You are lucky. I did not succeed in compiling the gdc master/HEAD 
on my Linux box,a t least not fully.

What system have you?
Jul 05 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/05/2013 03:34 PM, eles wrote:

 You are lucky. I did not succeed in compiling the gdc master/HEAD on my Linux
 box,a t least not fully.
 
 What system have you?


Ubuntu 13.04.  I have also compiled GDC successfully using 4.8.1 on a cluster in
my office which runs Ubuntu 12.04.
Jul 05 2013
parent reply "eles" <eles eles.com> writes:
On Friday, 5 July 2013 at 13:45:30 UTC, Joseph Rushton Wakeling 
wrote:

 On 07/05/2013 03:34 PM, eles wrote:
 Ubuntu 13.04.  I have also compiled GDC successfully using 
 4.8.1 on a cluster in
 my office which runs Ubuntu 12.04.


Ubuntu 13.10-x86_64 here (alpha). Do you use these instructions?

http://gdcproject.org/wiki/Installation#Debian.2FUbuntu_Linux

Do you mind updating those or publishing a script that does the 
compilation (the initial one and the one after each git pull).

Thanks.
Jul 05 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/05/2013 04:40 PM, eles wrote:

 On Friday, 5 July 2013 at 13:45:30 UTC, Joseph Rushton Wakeling wrote:

 On 07/05/2013 03:34 PM, eles wrote:
 Ubuntu 13.04.  I have also compiled GDC successfully using 4.8.1 on a cluster
in
 my office which runs Ubuntu 12.04.


 
 Ubuntu 13.10-x86_64 here (alpha). Do you use these instructions?


I'll describe exactly what I do.

Let's suppose that we have a directory called $(GDCDIR) that holds everything.

In $(GDCDIR)/dev I have my local copy of the GDC git repo.  This is GDC master,
not any of the 4.x branches.

In $(GDCDIR)/gcc-4.8.1 I have the GCC sources.  This is just the .tar.gz
download from one of the GCC mirrors, unzipped.

Then:

    cd $(GDCDIR)/dev
    ./setup-gcc.sh ../gcc-4.8.1
    mkdir ../objdir
    cd ../objdir
    ../gcc-4.8.1/configure --enable-languages=d --disable-multilib
--enable-checking=release --prefix=/opt/gdc
    make   [ with -j for as many processors as you can spare, it helps! ]

I think this matches pretty closely the general installation instructions:
http://www.gdcproject.org/wiki/Installation/General

It's no longer necessary to bother with the hassle of getting Debian/Ubuntu GCC
sources, as from 4.8 on GCC supports multiarch.  This also saves the hassle of
having to patch the Debian sources.

With the above done, if I pull in any updates from GDC master, I can rebuild as
follows:

    cd $(GDCDIR)/dev
    ./setup-gcc.sh --update ../gcc-4.8.1
    cd ../objdir
    make    [ still use -j as many processors as you can :-) ]

I should add that I arrived at this simple process substantially thanks to a
good deal of coaching and education from Iain, without whom GCC would have
defeated me :-)

When I did use .deb sources, I used gcc-snapshot -- I described the process
here: http://forum.dlang.org/thread/mailman.1605.1352199912.5162.d.gnu puremagic.com

... although watch out, there's one important typo in that set of instructions.

Anyway, the instructions in this email are probably the best to go with now.

Let me know how it goes for you ... :-)

Best wishes,

    -- Joe


P.S. You'll probably also want to install gdmd which these days has a separate
git repo.  Very easy to install -- you just need to tweak the Makefile so that
the install prefix goes where you want it to.
Jul 05 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Friday, 5 July 2013 at 16:35:26 UTC, Joseph Rushton Wakeling 
wrote:

 On 07/05/2013 04:40 PM, eles wrote:

 On Friday, 5 July 2013 at 13:45:30 UTC, Joseph Rushton 
 Wakeling wrote:

 On 07/05/2013 03:34 PM, eles wrote:
 Ubuntu 13.04.  I have also compiled GDC successfully using 
 4.8.1 on a cluster in
 my office which runs Ubuntu 12.04.


 
 Ubuntu 13.10-x86_64 here (alpha). Do you use these 
 instructions?


 I'll describe exactly what I do.

 Let's suppose that we have a directory called $(GDCDIR) that 
 holds everything.

 In $(GDCDIR)/dev I have my local copy of the GDC git repo.  
 This is GDC master,
 not any of the 4.x branches.

 In $(GDCDIR)/gcc-4.8.1 I have the GCC sources.  This is just 
 the .tar.gz
 download from one of the GCC mirrors, unzipped.

 Then:

     cd $(GDCDIR)/dev
     ./setup-gcc.sh ../gcc-4.8.1
     mkdir ../objdir
     cd ../objdir
     ../gcc-4.8.1/configure --enable-languages=d 
 --disable-multilib
 --enable-checking=release --prefix=/opt/gdc
     make   [ with -j for as many processors as you can spare, 
 it helps! ]


Well, it worked! Thanks a lot!


 It's no longer necessary to bother with the hassle of getting 
 Debian/Ubuntu GCC
 sources, as from 4.8 on GCC supports multiarch.  This also 
 saves the hassle of
 having to patch the Debian sources.


I never properly succeed into accomplishing all these steps. It 
patched, but it never compiled to the end. Thank you for the new 
method.



 With the above done, if I pull in any updates from GDC master, 
 I can rebuild as
 follows:

     cd $(GDCDIR)/dev
     ./setup-gcc.sh --update ../gcc-4.8.1
     cd ../objdir
     make    [ still use -j as many processors as you can :-) ]


I just can't wait to try this! I am looking impatiently for the 
next gdc commit...


 I should add that I arrived at this simple process 
 substantially thanks to a
 good deal of coaching and education from Iain, without whom GCC 
 would have
 defeated me :-)


Kudos, Iain!


 When I did use .deb sources, I used gcc-snapshot -- I described 
 the process
 here: 
 http://forum.dlang.org/thread/mailman.1605.1352199912.5162.d.gnu puremagic.com

 ... although watch out, there's one important typo in that set 
 of instructions.


If I will have the time, one day...


 Anyway, the instructions in this email are probably the best to 
 go with now.


Completely agree.


 Let me know how it goes for you ... :-)



Kudos, kudos, kudos.


 Best wishes,


Tha same to you!


     -- Joe


Eles


 P.S. You'll probably also want to install gdmd which these days 
 has a separate
 git repo.  Very easy to install -- you just need to tweak the 
 Makefile so that
 the install prefix goes where you want it to.


I will try that too.
Jul 08 2013
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/08/2013 11:43 AM, eles wrote:

 Well, it worked! Thanks a lot!


Excellent. :-)


 I never properly succeed into accomplishing all these steps. It patched, but it
 never compiled to the end. Thank you for the new method.


I also struggled for a long time with patching the sources.  I suspect part of
the problem was that I could not tell whether the build failures I was
experiencing were because I hadn't patched the sources properly, or for other
reasons.  At any rate, I never built gdc-4.7 successfully. :-\

Once I realized that I could use gcc-snapshot with gdc master, somehow it all
came together.  Now that gcc 4.8 has been officially released, of course, we
don't have to bother with that any more (... and there was much rejoicing:-).


 Kudos, Iain!


Also Johannes and Alex, and others.  It's been a big team effort :-)
Jul 08 2013
prev sibling parent "eles" <eles eles.com> writes:
On Friday, 5 July 2013 at 16:35:26 UTC, Joseph Rushton Wakeling 
wrote:

 On 07/05/2013 04:40 PM, eles wrote:

 On Friday, 5 July 2013 at 13:45:30 UTC, Joseph Rushton 
 Wakeling wrote:

 On 07/05/2013 03:34 PM, eles wrote:






I turned the instructions below in (quite-)general scripts:


 Then:

     cd $(GDCDIR)/dev
     ./setup-gcc.sh ../gcc-4.8.1
     mkdir ../objdir
     cd ../objdir
     ../gcc-4.8.1/configure --enable-languages=d 
 --disable-multilib
 --enable-checking=release --prefix=/opt/gdc
     make   [ with -j for as many processors as you can spare, 
 it helps! ]


$cat gdc-initialcompile.sh


CRTDIR=`pwd`
cd ${GDC_GDCSRC}
./setup-gcc.sh ${GDC_GCCSRC}
mkdir -p ${GDC_OBJDIR}
cd ${GDC_OBJDIR}
${GDC_GCCSRC}/configure --enable-languages=c,c++,d 
--disable-bootstrap --enable-checking=release --prefix=/usr
make -j8
sudo make install
cd ${CRTDIR}


 With the above done, if I pull in any updates from GDC master, 
 I can rebuild as
 follows:

     cd $(GDCDIR)/dev
     ./setup-gcc.sh --update ../gcc-4.8.1
     cd ../objdir
     make    [ still use -j as many processors as you can :-) ]


$cat gdc-updatecompile.sh


CRTDIR=`pwd`
cd ${GDC_GDCSRC}
./setup-gcc.sh --update ${GDC_GCCSRC}
mkdir -p ${GDC_OBJDIR}
cd ${GDC_OBJDIR}
make -j 8
sudo make install
cd ${CRTDIR}
Jul 18 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 5 July 2013 17:35, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 P.S. You'll probably also want to install gdmd which these days has a separate
 git repo.  Very easy to install -- you just need to tweak the Makefile so that
 the install prefix goes where you want it to.


On the note of that, is there anyone willing to take the keys for gdmd? :-)


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 05 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/05/2013 07:12 PM, Iain Buclaw wrote:

 On the note of that, is there anyone willing to take the keys for gdmd? :-)


Honestly, I'm not sure I'd know how to handle it.  I don't know Perl and the
kind of D programming that would be involved in re-implementing it in D is not
what I'm used to.

I did think of writing a configure script to allow the user to tweak a few
defaults (like the install prefix) but that actually seems overkill for
something so simple.

Is there anything that actually needs to be done apart from D-ifying it?
Jul 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 05, 2013 at 06:35:20PM +0200, Joseph Rushton Wakeling wrote:
[...]

 I'll describe exactly what I do.
 
 Let's suppose that we have a directory called $(GDCDIR) that holds
 everything.
 
 In $(GDCDIR)/dev I have my local copy of the GDC git repo.  This is
 GDC master, not any of the 4.x branches.
 
 In $(GDCDIR)/gcc-4.8.1 I have the GCC sources.  This is just the
 .tar.gz download from one of the GCC mirrors, unzipped.
 
 Then:
 
     cd $(GDCDIR)/dev
     ./setup-gcc.sh ../gcc-4.8.1
     mkdir ../objdir
     cd ../objdir
     ../gcc-4.8.1/configure --enable-languages=d --disable-multilib
 --enable-checking=release --prefix=/opt/gdc
     make   [ with -j for as many processors as you can spare, it helps! ]


Thanks so much for posting the exact steps! I finally got around to
retrying to build GDC with GCC-4.8. Using your steps above, it worked!!!

There was no trouble at all, except for an initial hiccup of having to
install libmpc-dev (but the configure script was pretty good about
stating exactly what is missing). The build went smoothly. To the above
steps, I'd only add 'make install' as the final step. :)



 I think this matches pretty closely the general installation
 instructions:
 http://www.gdcproject.org/wiki/Installation/General
 
 It's no longer necessary to bother with the hassle of getting
 Debian/Ubuntu GCC sources, as from 4.8 on GCC supports multiarch.
 This also saves the hassle of having to patch the Debian sources.


I think the fact that gcc-4.8 supports multiarch without needing to
setup the Debian sources (with the associated patching, etc.), made
things MUCH simpler and less error-prone than before.


 With the above done, if I pull in any updates from GDC master, I can
 rebuild as follows:
 
     cd $(GDCDIR)/dev
     ./setup-gcc.sh --update ../gcc-4.8.1
     cd ../objdir
     make    [ still use -j as many processors as you can :-) ]


Thanks, this will come in handy when I need to update GDC.



 I should add that I arrived at this simple process substantially
 thanks to a good deal of coaching and education from Iain, without
 whom GCC would have defeated me :-)


[...]

Well, I have to thank you for posting these steps. I have given up
building GDC for a long time until I tried it again today with your
instructions. And it worked!


T

-- 
Why ask rhetorical questions? -- JC
Jul 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 05, 2013 at 07:59:59PM +0200, Joseph Rushton Wakeling wrote:

 On 07/05/2013 07:12 PM, Iain Buclaw wrote:

 On the note of that, is there anyone willing to take the keys for
 gdmd? :-)


 
 Honestly, I'm not sure I'd know how to handle it.  I don't know Perl
 and the kind of D programming that would be involved in
 re-implementing it in D is not what I'm used to.


I know Perl quite well, though I'm somewhat rusty from not having used
it very much in the recent years. I'm willing to help if you have Perl
questions. :)



 I did think of writing a configure script to allow the user to tweak a
 few defaults (like the install prefix) but that actually seems
 overkill for something so simple.
 
 Is there anything that actually needs to be done apart from D-ifying
 it?


Wait, we're trying to D-ify gdmd?


T

-- 
I'm still trying to find a pun for "punishment"...
Jul 05 2013
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/05/2013 08:03 PM, H. S. Teoh wrote:

 Wait, we're trying to D-ify gdmd?


It was a suggestion of Iain's when he forked it off into a separate repo.  Seems
like a good idea -- demonstrates D's capabilities, probably makes it easier to
maintain, could make it easier to place back in the main project if/when the
frontend gets rewritten in D.
Jul 05 2013
parent reply "eles" <eles eles.com> writes:
On Friday, 5 July 2013 at 18:12:35 UTC, Joseph Rushton Wakeling 
wrote:

 On 07/05/2013 08:03 PM, H. S. Teoh wrote:

 Wait, we're trying to D-ify gdmd?


 It was a suggestion of Iain's when he forked it off into a 
 separate repo.  Seems
 like a good idea -- demonstrates D's capabilities, probably 
 makes it easier to
 maintain, could make it easier to place back in the main 
 project if/when the
 frontend gets rewritten in D.


Just me alone, I do not feel that I have enough time and 
competence to do that. But, what about to form a venture, the 
three of us? (JRW, HST and me, Iain already has a lot of job to 
do)

The goal would be to D-ify the gdmd.

I will learn some Perl in the process, but that's life...

So?
Jul 08 2013
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/08/2013 11:45 AM, eles wrote:

 Just me alone, I do not feel that I have enough time and competence to do that.
 But, what about to form a venture, the three of us? (JRW, HST and me, Iain
 already has a lot of job to do)
 
 The goal would be to D-ify the gdmd.
 
 I will learn some Perl in the process, but that's life...


My main concern is about regularity of time/attention I can give.  As you can
see from my contributions to Phobos, I tend to have brief periods of furious
activity and then long activity deserts -- which are mostly to do with
commitments elsewhere.

Anyway, I'll happily give it a go if the two of you are up for it, and
understand that at certain points I may just vanish for a while, at least
contribution-wise :-)

I figure it's something we can all learn something by doing and once this is
started we might be able to get others in as well.

Best wishes,

    -- Joe
Jul 08 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jul 08, 2013 at 12:50:02PM +0200, Joseph Rushton Wakeling wrote:

 On 07/08/2013 11:45 AM, eles wrote:

 Just me alone, I do not feel that I have enough time and competence
 to do that.  But, what about to form a venture, the three of us?
 (JRW, HST and me, Iain already has a lot of job to do)
 
 The goal would be to D-ify the gdmd.
 
 I will learn some Perl in the process, but that's life...


 
 My main concern is about regularity of time/attention I can give.  As
 you can see from my contributions to Phobos, I tend to have brief
 periods of furious activity and then long activity deserts -- which
 are mostly to do with commitments elsewhere.
 
 Anyway, I'll happily give it a go if the two of you are up for it, and
 understand that at certain points I may just vanish for a while, at
 least contribution-wise :-)
 
 I figure it's something we can all learn something by doing and once
 this is started we might be able to get others in as well.


[...]

I forked GDMD on github and took a first stab at D-ifying it:

	https://github.com/quickfur/GDMD/tree/dport

The new code is in gdmd.d -- I haven't updated the Makefile to build it
yet, so you'll have to compile it by hand.  It can do very simple
compiles now (list of .d files -> executable), including compile itself.
:) It can read dmd.conf and setup environment variables accordingly,
though I haven't actually tested whether it's really doing what I think
it's doing.  (Anybody up for writing unittests? ;-))

However, NO command-line options are parsed right now, so it can't
handle anything beyond just a list of .d files.  I also haven't tested
anything on Windows in spite of the version(Windows) blocks; so I've no
idea if that code actually works.  But it's a start. :)

I decided to write idiomatic D instead of a 1-to-1 translation of the
Perl version, so I took some liberties in the program structure.  But I
do use the Perl version as the go-to reference at each point, so it
*should* in theory be identical in functionality at the end.

Comments / flames / pull requests welcome. ;-)


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I
understand. -- Benjamin Franklin
Jul 09 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 I forked GDMD on github and took a first stab at D-ifying it:
 
 	https://github.com/quickfur/GDMD/tree/dport


Nice -- I'll try and have a play with that later :-)

First thing that strikes me -- and I know you're taking this from the original
script -- what's with the references to dmd.conf?  GDC has no dmd.conf that I
can recall (don't know whether it used to once upon a time), so this part of the
script may even be dangerous if it winds up trying to find a config file that
exists for dmd but not gdc/gdmd.

I'd have thought this could be deleted without problem.  If there _is_ a conf
script that needs using, it should be renamed to avoid potential clashes with
DMD proper.


 The new code is in gdmd.d -- I haven't updated the Makefile to build it
 yet, so you'll have to compile it by hand.  It can do very simple
 compiles now (list of .d files -> executable), including compile itself.
 :) It can read dmd.conf and setup environment variables accordingly,
 though I haven't actually tested whether it's really doing what I think
 it's doing.  (Anybody up for writing unittests? ;-))


I think that unittests can focus first on checking that gdmd input translates
into correct gdc output (as in, what you get right now running gdmd
--someoptions -vdmd).  That is, we can check each of the gdmd options singly and
ensure they translate to correct gdc call strings.

I'm not sure to what extent we'd need to test combinations of gdmd flags as
opposed to single flags.  There's also the whole bogeyman of contradictory flags
(e.g. one turns on the optimizations, one turns them off...).


 However, NO command-line options are parsed right now, so it can't
 handle anything beyond just a list of .d files.  I also haven't tested
 anything on Windows in spite of the version(Windows) blocks; so I've no
 idea if that code actually works.  But it's a start. :)


Start with an "unrecognized switch" error that applies to everything? :-)

If I recall right, Phobos has some flag-parsing stuff in there, so we should be
able to get that up and running fairly soon.


 I decided to write idiomatic D instead of a 1-to-1 translation of the
 Perl version, so I took some liberties in the program structure.  But I
 do use the Perl version as the go-to reference at each point, so it
 *should* in theory be identical in functionality at the end.


I think writing idiomatically from the get-go is a good idea.


 Comments / flames / pull requests welcome. ;-)


I'll be back with my big flaming torch and pitchfork after I've tested later
today ... ;-)

Thanks for getting this under way!

Best wishes,

    -- Joe
Jul 10 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/10/2013 10:03 AM, Joseph Rushton Wakeling wrote:

 I'll be back with my big flaming torch and pitchfork after I've tested later
 today ... ;-)


Not your fault, but that delimited string inside printUsage() runs into a lovely
syntax highlighting bug in d.vim:
https://github.com/JesseKPhillips/d.vim/issues/18
Jul 10 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 July 2013 11:05, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On 07/10/2013 10:03 AM, Joseph Rushton Wakeling wrote:

 I'll be back with my big flaming torch and pitchfork after I've tested later
 today ... ;-)


 Not your fault, but that delimited string inside printUsage() runs into a
lovely
 syntax highlighting bug in d.vim:
 https://github.com/JesseKPhillips/d.vim/issues/18



Which reminds me, need to implement delimited strings in cgdb.... :)


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 10 2013
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


    string findGDC(string argv0)
    {
        // FIXME: this does not work 100% of the time.
        auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
        auto targetPrefix = c[1];
        auto gdcDir = absolutePath(dirName(argv0));
        return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
    }

The "obvious" solution is to have a gdmd.conf file which specifies what gdc
executable to use and where to find it.  This should get round problems such as
gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.

The default would be to select the gdc used to actually build gdmd, with an
option to configure for alternative locations.

findGDC() should probably prioritize in this order:

    * If there's a gdmd.conf, use the gdcDir specified.  There probably
      needs to be a search priority of where to find the .conf file.

    * If not, use which gdc to identify what gdc to call
      (and possibly display a warning that there's no gdmd.conf?)

On a related note, can you clarify what the issues are with findScriptPath ... ?

    string findScriptPath(string argv0)
    {
        // FIXME: this is not 100% reliable; we need equivalent functionality to
        // Perl's FindBin.
        return absolutePath(dirName(argv0));
    }
Jul 10 2013
parent reply "eles" <eles eles.com> writes:
On Wednesday, 10 July 2013 at 10:24:17 UTC, Joseph Rushton 
Wakeling wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


     string findGDC(string argv0)
     {
         // FIXME: this does not work 100% of the time.
         auto c = match(baseName(argv0), 
 `^(.*-)?g?dmd(-.*)?$`).captures;
         auto targetPrefix = c[1];
         auto gdcDir = absolutePath(dirName(argv0));
         return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" 
 ~ c[2]);
     }


This is just bad:

main(string[] args) calls init(args) that calls findGDC(args[0]) 
that gives auto gdcDir = absolutePath(dirName(argv0));

Which is not good:

findGDC: argv0=gdmd
findGDC: dirName(argv0)=.
findGDC: gdcDir=/home/user/github/gdmd/.

That is: it will look for gdc in the current folder, which is not 
even the base folder of gdmd (eg. /usr/bin), but the working 
directory.

In other words, it looks for gdc in the current working folder.

Then it complains:

Not an executable file: /home/user/github/gdmd/gdc

which is understandable.

I think it should simply look on the PATH.
Jul 10 2013
parent reply "eles" <eles eles.com> writes:
On Wednesday, 10 July 2013 at 12:03:06 UTC, eles wrote:

 On Wednesday, 10 July 2013 at 10:24:17 UTC, Joseph Rushton 
 Wakeling wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


    string findGDC(string argv0)
    {
        // FIXME: this does not work 100% of the time.
        auto c = match(baseName(argv0), 
 `^(.*-)?g?dmd(-.*)?$`).captures;
        auto targetPrefix = c[1];
        auto gdcDir = absolutePath(dirName(argv0));
        return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" 
 ~ c[2]);
    }




Quick and unportable (Linux-only) drop-in replacement:

string findGDC(string argv0)
{
     // FIXME: this does not work 100% of the time.
     auto c = match(baseName(argv0), 
`^(.*-)?g?dmd(-.*)?$`).captures;
     auto targetPrefix = c[1];
	
	auto which = executeShell("which gdc");
	if (which.status == 0){
		writeln("Failed to execute which.");
	}
	else {
		writefln("which returned %s", which.output);
	}
	
	auto gdcDir = absolutePath(dirName(which.output));
	writefln("new findGDC: gdcDir=%s", gdcDir);
     return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ 
c[2]);
}
Jul 10 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Wednesday, 10 July 2013 at 12:14:39 UTC, eles wrote:

 On Wednesday, 10 July 2013 at 12:03:06 UTC, eles wrote:

 On Wednesday, 10 July 2013 at 10:24:17 UTC, Joseph Rushton 
 Wakeling wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


   string findGDC(string argv0)
   {
       // FIXME: this does not work 100% of the time.
       auto c = match(baseName(argv0), 
 `^(.*-)?g?dmd(-.*)?$`).captures;
       auto targetPrefix = c[1];
       auto gdcDir = absolutePath(dirName(argv0));
       return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" 
 ~ c[2]);
   }






Actually, I think this is better (diff wrt the Teoh's version):

diff --git a/gdmd.d b/gdmd.d
index 6607ce2..4c7e3eb 100644
--- a/gdmd.d
+++ b/gdmd.d
   -262,7 +262,14    Config init(string[] args)
  {
      auto cfg = new Config();
      cfg.scriptPath = findScriptPath(args[0]);
-    cfg.gdc = findGDC(args[0]);
+       auto which = executeShell("which gdc");
+       if (which.status == 0){
+               writeln("Failed to execute which.");
+       }
+       else {
+               writefln("which returned %s", which.output);
+       }
+    cfg.gdc = findGDC(which.output);
      cfg.linker = cfg.gdc;

      readDmdConf(cfg);
Jul 10 2013
parent "eles" <eles eles.com> writes:
On Wednesday, 10 July 2013 at 12:20:14 UTC, eles wrote:

 On Wednesday, 10 July 2013 at 12:14:39 UTC, eles wrote:

 On Wednesday, 10 July 2013 at 12:03:06 UTC, eles wrote:

 On Wednesday, 10 July 2013 at 10:24:17 UTC, Joseph Rushton 
 Wakeling wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


  string findGDC(string argv0)
  {
      // FIXME: this does not work 100% of the time.
      auto c = match(baseName(argv0), 
 `^(.*-)?g?dmd(-.*)?$`).captures;
      auto targetPrefix = c[1];
      auto gdcDir = absolutePath(dirName(argv0));
      return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" 
 ~ c[2]);
  }






 Actually, I think this is better


or worse. Since it asks findGDC() to unwind, then wind again the 
path towards gdc.

Isn't resonable to implement a Linux-like "which" function? Could 
even find its place in phobos.
Jul 10 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 July 2013 13:14, eles <eles eles.com> wrote:

 On Wednesday, 10 July 2013 at 12:03:06 UTC, eles wrote:

 On Wednesday, 10 July 2013 at 10:24:17 UTC, Joseph Rushton Wakeling wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)



    string findGDC(string argv0)
    {
        // FIXME: this does not work 100% of the time.
        auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
        auto targetPrefix = c[1];
        auto gdcDir = absolutePath(dirName(argv0));
        return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
    }





 Quick and unportable (Linux-only) drop-in replacement:


Christ on a bike.  What's wrong with:

import std.file;
import std.process : environment;

auto binpaths = environment.get("PATH");

foreach (path; binpaths.split(<delimiter>)
{
    auto exe = path ~ <dirsep> ~ "gdc";
    if (exists (exe)) {
      // found
    }
}


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 10 2013
parent reply "eles" <eles eles.com> writes:
On Wednesday, 10 July 2013 at 12:58:41 UTC, Iain Buclaw wrote:

 On 10 July 2013 13:14, eles <eles eles.com> wrote:

 On Wednesday, 10 July 2013 at 12:03:06 UTC, eles wrote:
 Quick and unportable (Linux-only) drop-in replacement:


 Christ on a bike.  What's wrong with:

 import std.file;
 import std.process : environment;

 auto binpaths = environment.get("PATH");

 foreach (path; binpaths.split(<delimiter>)
 {
     auto exe = path ~ <dirsep> ~ "gdc";
     if (exists (exe)) {
       // found
     }
 }


Almost nothing (just a bracket). So, to make Teoh's life easier:

diff --git a/gdmd.d b/gdmd.d
index 6607ce2..12c610f 100644
--- a/gdmd.d
+++ b/gdmd.d
   -141,13 +141,19    string findScriptPath(string argv0)
  /**
   * Finds GDC.
   */
-string findGDC(string argv0)
+string findGDC()
  {
-    // FIXME: this does not work 100% of the time.
-    auto c = match(baseName(argv0), 
`^(.*-)?g?dmd(-.*)?$`).captures;
-    auto targetPrefix = c[1];
-    auto gdcDir = absolutePath(dirName(argv0));
-    return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ 
c[2]);
+       auto binpaths = environment.get("PATH");
+
+       foreach (path; binpaths.split(pathSeparator))
+       {
+          auto exe = path ~ dirSeparator ~ "gdc";
+          if (exists (exe)) {
+            return exe;
+          }
+       }
+
+       return "";
  }

  /**
   -262,7 +268,7    Config init(string[] args)
  {
      auto cfg = new Config();
      cfg.scriptPath = findScriptPath(args[0]);
-    cfg.gdc = findGDC(args[0]);
+    cfg.gdc = findGDC();
      cfg.linker = cfg.gdc;

      readDmdConf(cfg);
Jul 10 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 10, 2013 at 03:39:48PM +0200, eles wrote:

 On Wednesday, 10 July 2013 at 12:58:41 UTC, Iain Buclaw wrote:

On 10 July 2013 13:14, eles <eles eles.com> wrote:

On Wednesday, 10 July 2013 at 12:03:06 UTC, eles wrote:
Quick and unportable (Linux-only) drop-in replacement:


Christ on a bike.  What's wrong with:

import std.file;
import std.process : environment;

auto binpaths = environment.get("PATH");

foreach (path; binpaths.split(<delimiter>)
{
    auto exe = path ~ <dirsep> ~ "gdc";
    if (exists (exe)) {
      // found
    }
}


 
 Almost nothing (just a bracket).


lol, you guys are a riot. :)



 So, to make Teoh's life easier:
 
 diff --git a/gdmd.d b/gdmd.d
 index 6607ce2..12c610f 100644
 --- a/gdmd.d
 +++ b/gdmd.d
    -141,13 +141,19    string findScriptPath(string argv0)
  /**
   * Finds GDC.
   */
 -string findGDC(string argv0)
 +string findGDC()
  {
 -    // FIXME: this does not work 100% of the time.
 -    auto c = match(baseName(argv0),
 `^(.*-)?g?dmd(-.*)?$`).captures;
 -    auto targetPrefix = c[1];
 -    auto gdcDir = absolutePath(dirName(argv0));
 -    return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~
 c[2]);
 +       auto binpaths = environment.get("PATH");
 +
 +       foreach (path; binpaths.split(pathSeparator))
 +       {
 +          auto exe = path ~ dirSeparator ~ "gdc";
 +          if (exists (exe)) {
 +            return exe;
 +          }
 +       }
 +
 +       return "";
  }
 
  /**
    -262,7 +268,7    Config init(string[] args)
  {
      auto cfg = new Config();
      cfg.scriptPath = findScriptPath(args[0]);
 -    cfg.gdc = findGDC(args[0]);
 +    cfg.gdc = findGDC();
      cfg.linker = cfg.gdc;
 
      readDmdConf(cfg);


I actually thought about this before I wrote what I did; the reason I
didn't do it, was because what the original script *appeared* to be
doing (I didn't check, so I'm not sure) is to first identify itself
(find the path to itself) then use that path to locate gdc. This is
pretty useful because you can have multiple gdc/gdmd installations:

	/usr
	/usr/bin
	/usr/bin/gdc
	/usr/bin/gdmd
	/opt
	/opt/bin
	/opt/bin/gdc
	/opt/bin/gdmd

then if you run /opt/bin/gdmd, it knows to invoke /opt/bin/gdc, and if
you run /usr/bin/gdmd, it knows to invoke /usr/bin/gdc.

But like Iain said, this is probably nitpicking about unimportant
things, so I think I'll just apply the patch and be done with it. :)
(Unless somebody comes up with an easy way of doing the above that
doesn't involve (too much) black magic.)

Also, I've added some naïve option-parsing since I wrote that previous
email, but I'm not 100% happy with it. It's too Perl-like. Last night
after going to bed I was thinking about whether it would be nicer to use
an AA or trie to match options instead of a long chain of if-else.
What's the usual "D way"?  (I *did* consider using std.getopt as I'm
accustomed to, but in this case DMD appears to have an idiomatic syntax
that std.getopt doesn't quite provide, so I didn't.)


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of
nominal lovers in dire need of being reminded to profess their
hypothetical love for their long-forgotten.
Jul 10 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 10 Jul 2013 07:14:27 -0700
schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:


 I actually thought about this before I wrote what I did; the reason I
 didn't do it, was because what the original script *appeared* to be
 doing (I didn't check, so I'm not sure) is to first identify itself
 (find the path to itself) then use that path to locate gdc.


Getting the real application path is not simple and not portable, but
if you really want to do that:

http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-executable-in-c
Jul 10 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/10/2013 05:25 PM, Johannes Pfau wrote:

 Getting the real application path is not simple and not portable, but
 if you really want to do that:


I found the same links and was wondering about that, but to be honest -- I think
Iain is right and this kind of stuff is overkill.

Let gdmd just be a script that invokes the default system gdc (i.e. the first in
the path).  To do that, we just need to get the PATH variable, and we don't even
need to care about where gdmd itself is located.
Jul 10 2013
parent Johannes Pfau <nospam example.com> writes:
Am Wed, 10 Jul 2013 18:23:54 +0200
schrieb Joseph Rushton Wakeling <joseph.wakeling webdrake.net>:


 On 07/10/2013 05:25 PM, Johannes Pfau wrote:

 Getting the real application path is not simple and not portable,
 but if you really want to do that:


 
 I found the same links and was wondering about that, but to be honest
 -- I think Iain is right and this kind of stuff is overkill.
 
 Let gdmd just be a script that invokes the default system gdc (i.e.
 the first in the path).  To do that, we just need to get the PATH
 variable, and we don't even need to care about where gdmd itself is
 located.


Right. And you could always still accept an optional parameter
--use-gdc=/path/gdc and an environment variable GDMD_GDC=/path/gdc.
Jul 10 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 10, 2013 at 06:23:54PM +0200, Joseph Rushton Wakeling wrote:

 On 07/10/2013 05:25 PM, Johannes Pfau wrote:

 Getting the real application path is not simple and not portable,
 but if you really want to do that:


 
 I found the same links and was wondering about that, but to be honest
 -- I think Iain is right and this kind of stuff is overkill.
 
 Let gdmd just be a script that invokes the default system gdc (i.e.
 the first in the path).  To do that, we just need to get the PATH
 variable, and we don't even need to care about where gdmd itself is
 located.


Yeah that what I've decided to go with. No point sweating over such
peripheral details when I should be more worried about the core
functionality of making gdmd actually work. :)


T

-- 
It always amuses me that Windows has a Safe Mode during bootup. Does
that mean that Windows is normally unsafe?
Jul 10 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 10 July 2013 at 15:25:02 UTC, Johannes Pfau wrote:

 Getting the real application path is not simple and not 
 portable, but
 if you really want to do that:

 http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-executable-in-c



On Windows you don't have to use GetModuleFileName as argv[0] has 
the full path.
Jul 10 2013
parent "Kagamin" <spam here.lot> writes:
Also this getexecname function is a good candidate for 
std.process.
Jul 10 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 July 2013 15:14, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Wed, Jul 10, 2013 at 03:39:48PM +0200, eles wrote:

 On Wednesday, 10 July 2013 at 12:58:41 UTC, Iain Buclaw wrote:

On 10 July 2013 13:14, eles <eles eles.com> wrote:

On Wednesday, 10 July 2013 at 12:03:06 UTC, eles wrote:
Quick and unportable (Linux-only) drop-in replacement:


Christ on a bike.  What's wrong with:

import std.file;
import std.process : environment;

auto binpaths = environment.get("PATH");

foreach (path; binpaths.split(<delimiter>)
{
    auto exe = path ~ <dirsep> ~ "gdc";
    if (exists (exe)) {
      // found
    }
}


 Almost nothing (just a bracket).


 lol, you guys are a riot. :)



 So, to make Teoh's life easier:

 diff --git a/gdmd.d b/gdmd.d
 index 6607ce2..12c610f 100644
 --- a/gdmd.d
 +++ b/gdmd.d
    -141,13 +141,19    string findScriptPath(string argv0)
  /**
   * Finds GDC.
   */
 -string findGDC(string argv0)
 +string findGDC()
  {
 -    // FIXME: this does not work 100% of the time.
 -    auto c = match(baseName(argv0),
 `^(.*-)?g?dmd(-.*)?$`).captures;
 -    auto targetPrefix = c[1];
 -    auto gdcDir = absolutePath(dirName(argv0));
 -    return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~
 c[2]);
 +       auto binpaths = environment.get("PATH");
 +
 +       foreach (path; binpaths.split(pathSeparator))
 +       {
 +          auto exe = path ~ dirSeparator ~ "gdc";
 +          if (exists (exe)) {
 +            return exe;
 +          }
 +       }
 +
 +       return "";
  }

  /**
    -262,7 +268,7    Config init(string[] args)
  {
      auto cfg = new Config();
      cfg.scriptPath = findScriptPath(args[0]);
 -    cfg.gdc = findGDC(args[0]);
 +    cfg.gdc = findGDC();
      cfg.linker = cfg.gdc;

      readDmdConf(cfg);


 I actually thought about this before I wrote what I did; the reason I
 didn't do it, was because what the original script *appeared* to be
 doing (I didn't check, so I'm not sure) is to first identify itself
 (find the path to itself) then use that path to locate gdc. This is
 pretty useful because you can have multiple gdc/gdmd installations:

         /usr
         /usr/bin
         /usr/bin/gdc
         /usr/bin/gdmd
         /opt
         /opt/bin
         /opt/bin/gdc
         /opt/bin/gdmd

 then if you run /opt/bin/gdmd, it knows to invoke /opt/bin/gdc, and if
 you run /usr/bin/gdmd, it knows to invoke /usr/bin/gdc.


Most people won't invoke the command by it's absolute path.  But for
those who do, I guess it's not unreasonable to check
/absolute/path/gdc too.  I was just raising eyebrows at
platform-dependant or "does not work 100% of the time" solutions. :o)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 10 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 July 2013 11:24, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


     string findGDC(string argv0)
     {
         // FIXME: this does not work 100% of the time.
         auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
         auto targetPrefix = c[1];
         auto gdcDir = absolutePath(dirName(argv0));
         return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
     }

 The "obvious" solution is to have a gdmd.conf file which specifies what gdc
 executable to use and where to find it.  This should get round problems such as
 gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.


Search all bin locations in $PATH for ./gdc - I'd imagine this is how
Perl's FindBin works...


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 10 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/10/2013 12:28 PM, Iain Buclaw wrote:

 On 10 July 2013 11:24, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


     string findGDC(string argv0)
     {
         // FIXME: this does not work 100% of the time.
         auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
         auto targetPrefix = c[1];
         auto gdcDir = absolutePath(dirName(argv0));
         return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
     }

 The "obvious" solution is to have a gdmd.conf file which specifies what gdc
 executable to use and where to find it.  This should get round problems such as
 gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.


 
 Search all bin locations in $PATH for ./gdc - I'd imagine this is how
 Perl's FindBin works...


In this case you need to take account of the possibility of multiple gdc/gdmd
versions being installed in different places.  So, ideally, a given install of
gdmd should be wedded to a given gdc.
Jul 10 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 July 2013 11:47, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On 07/10/2013 12:28 PM, Iain Buclaw wrote:

 On 10 July 2013 11:24, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 Comments / flames / pull requests welcome. ;-)


     string findGDC(string argv0)
     {
         // FIXME: this does not work 100% of the time.
         auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
         auto targetPrefix = c[1];
         auto gdcDir = absolutePath(dirName(argv0));
         return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
     }

 The "obvious" solution is to have a gdmd.conf file which specifies what gdc
 executable to use and where to find it.  This should get round problems such as
 gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.


 Search all bin locations in $PATH for ./gdc - I'd imagine this is how
 Perl's FindBin works...


 In this case you need to take account of the possibility of multiple gdc/gdmd
 versions being installed in different places.  So, ideally, a given install of
 gdmd should be wedded to a given gdc.


You think too hard about things that simply don't matter. You should
instead match behaviour of how shells such as bash or csh work when
there are more than one executable named 'foo' in /bin, /usr/bin, and
/usr/local/bin.

Incase you weren't aware, it is first match wins.


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 10 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/10/2013 12:56 PM, Iain Buclaw wrote:

 You think too hard about things that simply don't matter.


... scratches head furiously and thinks about how to respond to this ...

:-P
Jul 10 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 July 2013 12:24, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On 07/10/2013 12:56 PM, Iain Buclaw wrote:

 You think too hard about things that simply don't matter.


 ... scratches head furiously and thinks about how to respond to this ...

 :-P


http://25.media.tumblr.com/tumblr_lw997zALj91r1tloio1_500.gif


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 10 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 10, 2013 at 10:03:40AM +0200, Joseph Rushton Wakeling wrote:

 On 07/10/2013 02:07 AM, H. S. Teoh wrote:

 I forked GDMD on github and took a first stab at D-ifying it:
 
 	https://github.com/quickfur/GDMD/tree/dport


 
 Nice -- I'll try and have a play with that later :-)
 
 First thing that strikes me -- and I know you're taking this from the
 original script -- what's with the references to dmd.conf?  GDC has no
 dmd.conf that I can recall (don't know whether it used to once upon a
 time), so this part of the script may even be dangerous if it winds up
 trying to find a config file that exists for dmd but not gdc/gdmd.


True. I suppose the idea was to make gdmd a possible drop-in replacement
for dmd, so it would behave the same way as dmd would from the user's
POV. But this may be dangerous if you have both dmd and gdc installed,
and gdmd picks up the wrong settings intended only for dmd.



 I'd have thought this could be deleted without problem.  If there _is_
 a conf script that needs using, it should be renamed to avoid
 potential clashes with DMD proper.


OK. I'll make the name an enum that can be changed later. At least,
it'll be better than hardcoding the filename. ;-)



 The new code is in gdmd.d -- I haven't updated the Makefile to build
 it yet, so you'll have to compile it by hand.  It can do very simple
 compiles now (list of .d files -> executable), including compile
 itself.  :) It can read dmd.conf and setup environment variables
 accordingly, though I haven't actually tested whether it's really
 doing what I think it's doing.  (Anybody up for writing unittests?
 ;-))


 
 I think that unittests can focus first on checking that gdmd input
 translates into correct gdc output (as in, what you get right now
 running gdmd --someoptions -vdmd).  That is, we can check each of the
 gdmd options singly and ensure they translate to correct gdc call
 strings.
 
 I'm not sure to what extent we'd need to test combinations of gdmd
 flags as opposed to single flags.  There's also the whole bogeyman of
 contradictory flags (e.g. one turns on the optimizations, one turns
 them off...).


The problem I ran into when I thought about unittests was, the unittest
code basically has to do almost the same thing as what the code does
anyway, so it's not really *testing* the code per se, but testing your
ability to write the same code twice. I suppose we could test the more
tricky spots with explicit samples, though, like the parts parsed with
regexes.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft
system vulnerabilities cannot touch Linux---is priceless. -- Frustrated
system administrator.
Jul 10 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jul 09, 2013 at 05:07:59PM -0700, H. S. Teoh wrote:
[...]

 I forked GDMD on github and took a first stab at D-ifying it:
 
 	https://github.com/quickfur/GDMD/tree/dport


[...]

Update:
- Fixed the path issues raised earlier (thanks for all the feedback!)

- I've added a whole bunch more code now, and a good number of dmd
  options are now understood. Most of the common ones are now supported,
  like -c, -inline, -O, and a few others. There's still a lot left to
  do, though. It never truly dawned on me before just how many options
  dmd has!  (Fortunately it's nowhere near the sheer number in gcc/gdc.
  ;-))

- Unittests were added!! Now I can feel less shameful. :-P

- Now gdmd can handle -of, -od, and -op. However, dmd appears to be
  extremely quirky in this area (esp. when these options are used
  together). Apparently, if the argument to -of contains '/', it
  implicitly sets -od as well. Gdmd still doesn't quite match dmd in
  this area.  One particularly problematic case is:

  Given this directory structure:
	./src
	./src/test.d

  Running dmd -ofbin/prog produces:
  	./bin
	./bin/prog
	./prog.o	<-- problem

  The trouble with this case is that currently gdmd always compiles each
  source file separately (following the behaviour of the old Perl
  script), so we can't just rename the default test.o to prog.o. Also,
  IME, running gdc with too many .d files at once can sometimes cause
  memory problems, so doing it one at a time seems preferable.

- The makefile has been updated to build gdmd from gdmd.d instead of the
  Perl script. If you build with make DFLAGS=-fdebug, you'll get some
  verbose output that may help track down problems when gdmd
  misbehgaves=-fdebug, you'll get some verbose output that may help
  track down problems when gdmd misbehaves.

For the rest of the details, take a look at the git log. :) Gotta run
now.


T

-- 
A linguistics professor was lecturing to his class one day.
"In English," he said, "A double negative forms a positive. In some
languages, though, such as Russian, a double negative is still a
negative. However, there is no language wherein a double positive can
form a negative."
A voice from the back of the room piped up, "Yeah, yeah."
Jul 10 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On Jul 11, 2013 1:28 AM, "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Tue, Jul 09, 2013 at 05:07:59PM -0700, H. S. Teoh wrote:
 [...]

 I forked GDMD on github and took a first stab at D-ifying it:

       https://github.com/quickfur/GDMD/tree/dport


 [...]

 Update:
 - Fixed the path issues raised earlier (thanks for all the feedback!)

 - I've added a whole bunch more code now, and a good number of dmd
   options are now understood. Most of the common ones are now supported,
   like -c, -inline, -O, and a few others. There's still a lot left to
   do, though. It never truly dawned on me before just how many options
   dmd has!  (Fortunately it's nowhere near the sheer number in gcc/gdc.
   ;-))

 - Unittests were added!! Now I can feel less shameful. :-P

 - Now gdmd can handle -of, -od, and -op. However, dmd appears to be
   extremely quirky in this area (esp. when these options are used
   together). Apparently, if the argument to -of contains '/', it
   implicitly sets -od as well. Gdmd still doesn't quite match dmd in
   this area.  One particularly problematic case is:

   Given this directory structure:
         ./src
         ./src/test.d

   Running dmd -ofbin/prog produces:
         ./bin
         ./bin/prog
         ./prog.o        <-- problem

   The trouble with this case is that currently gdmd always compiles each
   source file separately (following the behaviour of the old Perl


Are you sure on that?  :-)

My memory might be bad in this respect, but I seem to recall the script
explicitly set the output program / object file name. (See below for why
that matters ).


   script), so we can't just rename the default test.o to prog.o. Also,
   IME, running gdc with too many .d files at once can sometimes cause
   memory problems, so doing it one at a time seems preferable.


Running dmd with too many .d files causes the same memory problems, but
they tend to be short lived due to the speed of the compilation.

The difference between single and multiple file compilation is very subtle
in gdc since the switch to LTO.




People from a dmd background I found expected the latter, and separate
compilation also comes with its own quirks that don't occur during single
compilation of all sources (the most common suggested work around for this
being -femit-templates, though should give the switch -fonly some lovin'
someday).

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 11 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

 On Jul 11, 2013 1:28 AM, "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


[...]

   The trouble with this case is that currently gdmd always compiles
   each source file separately (following the behaviour of the old
   Perl


 
 Are you sure on that?  :-)


Heh, you're right, I misread the Perl script (or rather, didn't pay
attention to that little flag named $combine). The original script does
indeed compile everything all at once. I'll have to change my new
version to do the same. :)



 My memory might be bad in this respect, but I seem to recall the
 script explicitly set the output program / object file name. (See
 below for why that matters ).


I've set up the new version to always specify output filenames too. But
I missed the part where separate compilation *isn't* the default. :)



   script), so we can't just rename the default test.o to prog.o.
   Also, IME, running gdc with too many .d files at once can
   sometimes cause memory problems, so doing it one at a time seems
   preferable.


 
 Running dmd with too many .d files causes the same memory problems,
 but they tend to be short lived due to the speed of the compilation.


I'll have to experiment with that one a little bit more. I have a
particular project that appears to use a combination of templates that
causes the old gdc-4.6 to crash / produce wrong results when compiled
all together, but I haven't tried it with gdc-4.8 yet.



 The difference between single and multiple file compilation is very
 subtle in gdc since the switch to LTO.
 


 
 People from a dmd background I found expected the latter, and separate
 compilation also comes with its own quirks that don't occur during
 single compilation of all sources (the most common suggested work
 around for this being -femit-templates, though should give the switch
 -fonly some lovin' someday).


[...]

You're right, I'll have to rewrite gdmd.compile() to do everything in
one go instead of compiling separately, as I have it now.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by
throwing someone out a window", or more recently "to remove Windows from
a computer and replace it with something useful". :-) -- John Cowan
Jul 11 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

 On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

 On Jul 11, 2013 1:28 AM, "H. S. Teoh" <hsteoh quickfur.ath.cx> 
 wrote:


 Heh, you're right, I misread the Perl script (or rather, didn't 
 pay
 attention to that little flag named $combine). The original 
 script does
 indeed compile everything all at once. I'll have to change my 
 new
 version to do the same. :)


The perl script achieves that by adding the "-combine" option to
the invocation of gdc (perl/l626). That is a deprecated option.
Newer one is to use "-flto" and, also, if the output is an exe,
"-fwhole-program" could be added, too.

see here:

http://lwn.net/Articles/387122/

I think there is no problem to provide "-flto" to gdc even if
there is just only one source file (unlike the "$combine" flag
that is activated only for multiple source files: perl/l490).

More, apparently, since gcc 4.6, that "-combine" flag seems to be
inert:

http://gcc.gnu.org/gcc-4.6/changes.html
Jul 15 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 July 2013 15:25, eles <eles eles.com> wrote:

 On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

 On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

 On Jul 11, 2013 1:28 AM, "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 Heh, you're right, I misread the Perl script (or rather, didn't pay
 attention to that little flag named $combine). The original script does
 indeed compile everything all at once. I'll have to change my new
 version to do the same. :)



 The perl script achieves that by adding the "-combine" option to
 the invocation of gdc (perl/l626). That is a deprecated option.
 Newer one is to use "-flto" and, also, if the output is an exe,
 "-fwhole-program" could be added, too.


No, simply explicitly setting an -o object file is enough to achieve
the behaviour of the old "-combine" switch in prior gcc releases.

You don't want to be using -flto, -flto does not work with the D frontend.

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 15 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

 On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

 On Jul 11, 2013 1:28 AM, "H. S. Teoh" <hsteoh quickfur.ath.cx>


 You're right, I'll have to rewrite gdmd.compile() to do 
 everything in
 one go instead of compiling separately, as I have it now.


This? (BTW, how to send github pull requests to a fork of the 
main repo?)

diff --git a/gdmd.d b/gdmd.d
index bb310aa..dd08900 100644
--- a/gdmd.d
+++ b/gdmd.d
   -513,7 +513,7    void parseArgs(Config cfg, string[] _args)
  /**
   * Compiles the given source files.
   */
-void compile(Config cfg)
+void compile_only(Config cfg)
  {
      foreach (srcfile; cfg.sources) {
          auto objfile = cfg.src2obj(srcfile);
   -590,18 +590,18    unittest
  }

  /**
- * Links the given sources files into the final executable.
+ * Compiles and links the given sources files into the final 
executable.
   */
-void link(Config cfg)
+void compile_and_link(Config cfg)
  {
-    /*
+       /*
       * Construct link command
       */
-    auto cmd = [ cfg.linker ] ~ cfg.linkFlags;
+    auto cmd = [ cfg.linker ] ~ cfg.gdcFlags ~ cfg.linkFlags;

      // Collect all object files.
      foreach (srcfile; cfg.sources) {
-        cmd ~= cfg.src2obj(srcfile);
+        cmd ~= srcfile;
      }

      // Create target directory if it doesn't exist yet.
   -619,7 +619,7    void link(Config cfg)
      debug writeln("[exec] ", cmd.join(" "));
      auto rc = execute(cmd);
      if (rc.status != 0)
-        throw new Exception("Link failed: %s".format(rc.output));
+        throw new Exception("Compile and link failed: 
%s".format(rc.output));
  }

  /**
   -636,10 +636,12    int main(string[] args)
              exit(0);
          }

-        compile(cfg);
-
-        if (!cfg.dontLink)
-            link(cfg);
+       if (cfg.dontLink) {
+               compile_only(cfg);
+       }
+       else {
+               compile_and_link(cfg);
+       }

          return 0;
      } catch(ExitException e) {
Jul 18 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 18, 2013 at 10:22:14AM +0200, eles wrote:

 On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

On Jul 11, 2013 1:28 AM, "H. S. Teoh" <hsteoh quickfur.ath.cx>


You're right, I'll have to rewrite gdmd.compile() to do everything in
one go instead of compiling separately, as I have it now.


 
 This? (BTW, how to send github pull requests to a fork of the main
 repo?)


I think you have to fork my fork in order to make a pull, I don't know
if github supports pull requests to a different fork of the main repo.



 diff --git a/gdmd.d b/gdmd.d
 index bb310aa..dd08900 100644
 --- a/gdmd.d
 +++ b/gdmd.d
    -513,7 +513,7    void parseArgs(Config cfg, string[] _args)
  /**
   * Compiles the given source files.
   */
 -void compile(Config cfg)
 +void compile_only(Config cfg)
  {
      foreach (srcfile; cfg.sources) {
          auto objfile = cfg.src2obj(srcfile);
    -590,18 +590,18    unittest
  }
 
  /**
 - * Links the given sources files into the final executable.
 + * Compiles and links the given sources files into the final
 executable.
   */
 -void link(Config cfg)
 +void compile_and_link(Config cfg)
  {
 -    /*
 +       /*
       * Construct link command
       */
 -    auto cmd = [ cfg.linker ] ~ cfg.linkFlags;
 +    auto cmd = [ cfg.linker ] ~ cfg.gdcFlags ~ cfg.linkFlags;
 
      // Collect all object files.
      foreach (srcfile; cfg.sources) {
 -        cmd ~= cfg.src2obj(srcfile);
 +        cmd ~= srcfile;
      }
 
      // Create target directory if it doesn't exist yet.
    -619,7 +619,7    void link(Config cfg)
      debug writeln("[exec] ", cmd.join(" "));
      auto rc = execute(cmd);
      if (rc.status != 0)
 -        throw new Exception("Link failed: %s".format(rc.output));
 +        throw new Exception("Compile and link failed:
 %s".format(rc.output));
  }
 
  /**
    -636,10 +636,12    int main(string[] args)
              exit(0);
          }
 
 -        compile(cfg);
 -
 -        if (!cfg.dontLink)
 -            link(cfg);
 +       if (cfg.dontLink) {
 +               compile_only(cfg);
 +       }
 +       else {
 +               compile_and_link(cfg);
 +       }
 
          return 0;
      } catch(ExitException e) {


Thanks for the diff! I'll try to find some time today to apply it.


T

-- 
Тише едешь, дальше будешь.
Jul 18 2013
parent reply "eles" <eles eles.com> writes:
On Thursday, 18 July 2013 at 17:10:10 UTC, H. S. Teoh wrote:

 On Thu, Jul 18, 2013 at 10:22:14AM +0200, eles wrote:

 On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

On Jul 11, 2013 1:28 AM, "H. S. Teoh" 
<hsteoh quickfur.ath.cx>






 I think you have to fork my fork in order to make a pull, I 
 don't know
 if github supports pull requests to a different fork of the 
 main repo.


I did try that, but it forks the original repo instead.

I think, in the theory, only Iain could be able to integrate your 
(and mine) pull requests into his repository.

What about you getting the keys of the main gdmd repo and move 
there the D-port of gdmd?

You already did tremendous amount of work, to the point that the 
old version of gdmd (the Perl script) could be already dropped 
(or kept for historical reasons).
Jul 19 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2013 at 10:53:27AM +0200, eles wrote:

 On Thursday, 18 July 2013 at 17:10:10 UTC, H. S. Teoh wrote:

On Thu, Jul 18, 2013 at 10:22:14AM +0200, eles wrote:

On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

On Jul 11, 2013 1:28 AM, "H. S. Teoh"
<hsteoh quickfur.ath.cx>






I think you have to fork my fork in order to make a pull, I don't
know if github supports pull requests to a different fork of the main
repo.


 
 I did try that, but it forks the original repo instead.


Oh.



 I think, in the theory, only Iain could be able to integrate your (and
 mine) pull requests into his repository.


Really? That's kinda... pointless, isn't it? 'cos why would my fork page
have the "pull requests" tab?



 What about you getting the keys of the main gdmd repo and move there
 the D-port of gdmd?
 
 You already did tremendous amount of work, to the point that the old
 version of gdmd (the Perl script) could be already dropped (or kept
 for historical reasons).


Not really, there are still some dmd options that dmd-script supports,
but gdmd.d doesn't yet.


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain
Jul 19 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
 
 

 I think, in the theory, only Iain could be able to integrate your
 (and mine) pull requests into his repository.


 
 Really? That's kinda... pointless, isn't it? 'cos why would my fork
 page have the "pull requests" tab?


If you click "pull request" or "compare" on github there should be a
bar here:
http://i.imgur.com/x3BJpeH.png

Click edit. Now you can select target repository, target branch, source
repository and source branch. (This is with the new github interface)
Jul 19 2013
parent "eles" <eles eles.com> writes:
On Friday, 19 July 2013 at 19:35:21 UTC, Johannes Pfau wrote:

 Click edit. Now you can select target repository, target 
 branch, source
 repository and source branch. (This is with the new github 
 interface)


Wow! It worked! Many thanks!

Here's the result:

https://github.com/quickfur/GDMD/pull/1/files
Jul 19 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Friday, 19 July 2013 at 19:06:41 UTC, H. S. Teoh wrote:

 On Fri, Jul 19, 2013 at 10:53:27AM +0200, eles wrote:

 On Thursday, 18 July 2013 at 17:10:10 UTC, H. S. Teoh wrote:

On Thu, Jul 18, 2013 at 10:22:14AM +0200, eles wrote:

On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

On Jul 11, 2013 1:28 AM, "H. S. Teoh"










 Not really, there are still some dmd options that dmd-script 
 supports,
 but gdmd.d doesn't yet.


Do you mind making a list of those (here) and suggest how to 
distribute those between us?

This will avoid duplicate work and will allow us keeping some 
focus.

BTW: I think it is better to start a new thread, maybe: "gdmd 
port"
Jul 22 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jul 22, 2013 at 10:38:36AM +0200, eles wrote:

 On Friday, 19 July 2013 at 19:06:41 UTC, H. S. Teoh wrote:


[...]

Not really, there are still some dmd options that dmd-script
supports, but gdmd.d doesn't yet.


 
 Do you mind making a list of those (here) and suggest how to
 distribute those between us?
 
 This will avoid duplicate work and will allow us keeping some focus.


Actually, I haven't had time to do much with gdmd for the past week or
so, and probably won't have that much time this week either. If you want
to work on it this week, please go ahead.

As for what is/isn't implemented yet: if you look at parseArgs(),
there's a bunch of "TBD" comments that indicate which options are
currently recognized but not implemented.

I basically went through the corresponding code in dmd-script in the
order it appears in the latter, and currently I've gotten to -op. So
pretty much everything that follows -op in dmd-script isn't recognized
yet, and needs to be implemented (in addition to the above options that
are currently recognized but not yet implemented).

Besides the actual options themselves, I'm not very happy with the
current implementation of parseArgs(). The most egregious fault with it
is that it's using a bunch of regexes that matches *both* options *and*
filenames. I'm pretty sure there are some obscure corner cases where
this is going to cause bugs. This function really should first check the
first character of each command-line argument, and if it begins with
"-", call the code that parses options, otherwise, call the code that
parses filenames.

Besides that, I think the majority of the options can be put into a
static AA for fast lookup of options without arguments. Unfortunately,
due to DMD's idiosyncratic command-line syntax, we can't do this for
options with arguments, so we'll still have to use regexes for that.
Alternatively, another approach is to parse it char-by-char until we
reach the argument part of the option, then use slicing to pick up the
latter. This would be more tedious, though, and I'm not sure it's worth
the effort (this *is* just parsing command-line options, not a
performance critical inner loop). Probably the AA lookup + regexes
approach is Good Enough(tm).



 BTW: I think it is better to start a new thread, maybe: "gdmd port"


Done.


T

-- 
Heads I win, tails you lose.
Jul 22 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 July 2013 20:05, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Fri, Jul 19, 2013 at 10:53:27AM +0200, eles wrote:

 On Thursday, 18 July 2013 at 17:10:10 UTC, H. S. Teoh wrote:

On Thu, Jul 18, 2013 at 10:22:14AM +0200, eles wrote:

On Thursday, 11 July 2013 at 14:42:09 UTC, H. S. Teoh wrote:

On Thu, Jul 11, 2013 at 08:09:33AM +0100, Iain Buclaw wrote:

On Jul 11, 2013 1:28 AM, "H. S. Teoh"
<hsteoh quickfur.ath.cx>






I think you have to fork my fork in order to make a pull, I don't
know if github supports pull requests to a different fork of the main
repo.


 I did try that, but it forks the original repo instead.


 Oh.



 I think, in the theory, only Iain could be able to integrate your (and
 mine) pull requests into his repository.


 Really? That's kinda... pointless, isn't it? 'cos why would my fork page
 have the "pull requests" tab?



 What about you getting the keys of the main gdmd repo and move there
 the D-port of gdmd?

 You already did tremendous amount of work, to the point that the old
 version of gdmd (the Perl script) could be already dropped (or kept
 for historical reasons).


 Not really, there are still some dmd options that dmd-script supports,
 but gdmd.d doesn't yet.


 T


So are you two guys axeoth and quickfur?


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 19 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2013 at 09:26:17PM +0100, Iain Buclaw wrote:

 On 19 July 2013 20:05, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Fri, Jul 19, 2013 at 10:53:27AM +0200, eles wrote:




[...]

 What about you getting the keys of the main gdmd repo and move
 there the D-port of gdmd?

 You already did tremendous amount of work, to the point that the
 old version of gdmd (the Perl script) could be already dropped (or
 kept for historical reasons).


 Not really, there are still some dmd options that dmd-script
 supports, but gdmd.d doesn't yet.




[...]

 So are you two guys axeoth and quickfur?


[...]

I'm quickfur. I'm guessing eles is axeoth.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need
before which you can't deliver after.
Jul 19 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 July 2013 21:39, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Fri, Jul 19, 2013 at 09:26:17PM +0100, Iain Buclaw wrote:

 On 19 July 2013 20:05, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Fri, Jul 19, 2013 at 10:53:27AM +0200, eles wrote:




 [...]

 What about you getting the keys of the main gdmd repo and move
 there the D-port of gdmd?

 You already did tremendous amount of work, to the point that the
 old version of gdmd (the Perl script) could be already dropped (or
 kept for historical reasons).


 Not really, there are still some dmd options that dmd-script
 supports, but gdmd.d doesn't yet.




 [...]

 So are you two guys axeoth and quickfur?


 [...]

 I'm quickfur. I'm guessing eles is axeoth.


Added you to Team GDMD.  =)


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 19 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/19/2013 09:05 PM, H. S. Teoh wrote:

 Not really, there are still some dmd options that dmd-script supports,
 but gdmd.d doesn't yet.


On that note, is there a reason not to use std.getopt for the option parsing?
Perhaps that it doesn't support single-hyphen option flags of more than one
character, such as dmd uses?
Jul 31 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 31, 2013 at 01:40:31PM +0200, Joseph Rushton Wakeling wrote:

 On 07/19/2013 09:05 PM, H. S. Teoh wrote:

 Not really, there are still some dmd options that dmd-script
 supports, but gdmd.d doesn't yet.


 
 On that note, is there a reason not to use std.getopt for the option
 parsing?  Perhaps that it doesn't support single-hyphen option flags
 of more than one character, such as dmd uses?


The main reason is that dmd command-line syntax is somewhat incompatible
with std.getopt. (And also that std.getopt has some quirks w.r.t. to
"usual" Posix-style command-line arguments, but then again, dmd itself
is rather quirky so that's moot.) The biggest problem is multi-character
flags that take arguments without an intervening space, like
-ofprogram.exe, which std.getopt simply can't handle.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by
throwing someone out a window", or more recently "to remove Windows from
a computer and replace it with something useful". :-) -- John Cowan
Jul 31 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/05/2013 08:02 PM, H. S. Teoh wrote:

 Thanks so much for posting the exact steps! I finally got around to
 retrying to build GDC with GCC-4.8. Using your steps above, it worked!!!


Fantastic!  So glad it finally worked for you.


 There was no trouble at all, except for an initial hiccup of having to
 install libmpc-dev (but the configure script was pretty good about
 stating exactly what is missing). The build went smoothly. To the above
 steps, I'd only add 'make install' as the final step. :)


Yes, I think there are one or two dependencies not mentioned on the GDC wiki
which I discovered when first trying to build it.  There's certainly an
unmentioned package which is needed for the test suite.

One of these days I'll have to set up a fresh system and try a build on it just
to document what they are.


 I think the fact that gcc-4.8 supports multiarch without needing to
 setup the Debian sources (with the associated patching, etc.), made
 things MUCH simpler and less error-prone than before.


Yes, though once I discovered the trick of using gcc-snapshot (bad idea, but it
worked:-) I never had any problems patching the sources.  It was just an
annoyance to have to do it.


 With the above done, if I pull in any updates from GDC master, I can
 rebuild as follows:

     cd $(GDCDIR)/dev
     ./setup-gcc.sh --update ../gcc-4.8.1
     cd ../objdir
     make    [ still use -j as many processors as you can :-) ]


 
 Thanks, this will come in handy when I need to update GDC.


Thank Iain, who told me about it :-)  Before that, I'd actually been deleting
and re-unzipping the whole gcc-4.8.1 directory, meaning a complete rebuild every
time.  Rebuilding GDC has recently become much quicker for me ... :-)


 Well, I have to thank you for posting these steps. I have given up
 building GDC for a long time until I tried it again today with your
 instructions. And it worked!


I know exactly the feeling, I also had a long period of thinking I'd never get
it working.  I'm very happy these instructions were useful to you -- and I have
to in turn thank the various people who helped me back then :-)
Jul 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 05, 2013 at 08:22:54PM +0200, Joseph Rushton Wakeling wrote:

 On 07/05/2013 08:02 PM, H. S. Teoh wrote:

 Thanks so much for posting the exact steps! I finally got around to
 retrying to build GDC with GCC-4.8. Using your steps above, it
 worked!!!


 
 Fantastic!  So glad it finally worked for you.
 

 There was no trouble at all, except for an initial hiccup of having
 to install libmpc-dev (but the configure script was pretty good
 about stating exactly what is missing). The build went smoothly. To
 the above steps, I'd only add 'make install' as the final step. :)


 
 Yes, I think there are one or two dependencies not mentioned on the GDC wiki
 which I discovered when first trying to build it.  There's certainly an
 unmentioned package which is needed for the test suite.


I think libmpc-dev is mentioned on the wiki as a prerequisite (well,
libmpc is, but hopefully Debian users know to install the -dev packages
as well).



 One of these days I'll have to set up a fresh system and try a build
 on it just to document what they are.


Good idea. It should be relatively easy to setup a chroot for this
purpose, if you don't want to go all-out to have a brand new system.
IIRC it's just a matter of installing and running debootstrap to create
a bare-minimum system in a subdir, which you can then chroot into and
install the necessary packages.



 I think the fact that gcc-4.8 supports multiarch without needing to
 setup the Debian sources (with the associated patching, etc.), made
 things MUCH simpler and less error-prone than before.


 
 Yes, though once I discovered the trick of using gcc-snapshot (bad
 idea, but it worked:-) I never had any problems patching the sources.
 It was just an annoyance to have to do it.


Well, for me it may have been the breaking factor. :-P  I suspect,
anyway. I never bothered to look deeper to find out what was breaking.
And now that gcc-4.8 is working, I'm not going back to figure out why it
didn't work before!



 With the above done, if I pull in any updates from GDC master, I
 can rebuild as follows:

     cd $(GDCDIR)/dev
     ./setup-gcc.sh --update ../gcc-4.8.1
     cd ../objdir
     make    [ still use -j as many processors as you can :-) ]


 
 Thanks, this will come in handy when I need to update GDC.


 
 Thank Iain, who told me about it :-)  Before that, I'd actually been
 deleting and re-unzipping the whole gcc-4.8.1 directory, meaning a
 complete rebuild every time.  Rebuilding GDC has recently become much
 quicker for me ... :-)
 

 Well, I have to thank you for posting these steps. I have given up
 building GDC for a long time until I tried it again today with your
 instructions. And it worked!


 
 I know exactly the feeling, I also had a long period of thinking I'd
 never get it working.  I'm very happy these instructions were useful
 to you -- and I have to in turn thank the various people who helped me
 back then :-)


Well, now that I've successfully built gdc-4.8, I'm wondering if I
should work on getting it into the Debian repo? Or is somebody already
working on that? Iain?

(I realize it may not be quite as smooth as building from upstream
gcc-4.8, since I'll need to apply Debian-specific patches, etc., but at
least I have a working baseline to compare with when something goes
wrong, as opposed to completely shooting in the dark.) 


T

-- 
Obviously, some things aren't very obvious.
Jul 05 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 5 July 2013 19:32, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 Well, now that I've successfully built gdc-4.8, I'm wondering if I
 should work on getting it into the Debian repo? Or is somebody already
 working on that? Iain?


1. Congrats, the first time building gcc is always the hardest. :o)

2. You are at least a month behind on that.
  a. gdc has been merged in with the gcc source package in Debian.
  b. 4.8 is in unstable (based off 2.062 though).
  c. I have been receiving lots of emails from the debbuilder about
gdc building status on all of debian's arch's, and success/failures in
the testsuite / unittester.  :o)




--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 05 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 05, 2013 at 10:04:08PM +0100, Iain Buclaw wrote:

 On 5 July 2013 19:32, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 Well, now that I've successfully built gdc-4.8, I'm wondering if I
 should work on getting it into the Debian repo? Or is somebody
 already working on that? Iain?


 
 1. Congrats, the first time building gcc is always the hardest. :o)


Well, it wasn't quite my first time. ;) I had managed to get GDC to
build with 4.7 before, just not git HEAD.



 2. You are at least a month behind on that.


Ahhahaha... I must be growing old. Took what felt like a few days off
following GDC developments due to being busy with other things, and come
back to discover things have changed so much. :-P



   a. gdc has been merged in with the gcc source package in Debian.


Oooh nice!! Heh, now I know I'm getting old. I haven't even noticed
gdc-4.8 being listed among the unstable packages now!



   b. 4.8 is in unstable (based off 2.062 though).


Well, 2.062 is still better than whatever gdc-4.6 was based on, which
IIRC was really old.



   c. I have been receiving lots of emails from the debbuilder about
 gdc building status on all of debian's arch's, and success/failures in
 the testsuite / unittester.  :o)


[...]

Very nice. :)


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom
Jul 05 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 5 July 2013 14:45, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On 07/05/2013 03:34 PM, eles wrote:

 You are lucky. I did not succeed in compiling the gdc master/HEAD on my Linux
 box,a t least not fully.

 What system have you?


 Ubuntu 13.04.  I have also compiled GDC successfully using 4.8.1 on a cluster
in
 my office which runs Ubuntu 12.04.


You use gdc at work? :o)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jul 05 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/05/2013 04:25 PM, Iain Buclaw wrote:

 You use gdc at work? :o)


Yup.  The day job is in a research group, so I can use what I like. :-)

I did have some worries that if I and colleagues started sharing code we'd have
trouble, as they're mostly wedded to C/C++/Python combinations (and occasionally
Fortran:-), but in practice we tend to each do independent implementations of
simulations.  In my experience this is a good thing as this way everyone learns
how to do stuff, and any discrepancies usually lead to identification of bugs.
Jul 05 2013