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
next sibling parent 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
prev sibling next sibling 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 "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 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
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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent 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
prev sibling parent "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
prev sibling 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
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 parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bb03d3681b4bb04e13713ce
Content-Type: text/plain; charset=ISO-8859-1

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. gdc foo.d bar.d. # compiled separately. gdc foo.d bar.d -o exe # compiled together. 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'; --047d7bb03d3681b4bb04e13713ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p>On Jul 11, 2013 1:28 AM, &quot;H. S. Teoh&quot; &lt;<a href=3D"mailto:hs= teoh quickfur.ath.cx">hsteoh quickfur.ath.cx</a>&gt; wrote:<br> &gt;<br> &gt; On Tue, Jul 09, 2013 at 05:07:59PM -0700, H. S. Teoh wrote:<br> &gt; [...]<br> &gt; &gt; I forked GDMD on github and took a first stab at D-ifying it:<br> &gt; &gt;<br> &gt; &gt; =A0 =A0 =A0 <a href=3D"https://github.com/quickfur/GDMD/tree/dpor= t">https://github.com/quickfur/GDMD/tree/dport</a><br> &gt; [...]<br> &gt;<br> &gt; Update:<br> &gt; - Fixed the path issues raised earlier (thanks for all the feedback!)<= br> &gt;<br> &gt; - I&#39;ve added a whole bunch more code now, and a good number of dmd= <br> &gt; =A0 options are now understood. Most of the common ones are now suppor= ted,<br> &gt; =A0 like -c, -inline, -O, and a few others. There&#39;s still a lot le= ft to<br> &gt; =A0 do, though. It never truly dawned on me before just how many optio= ns<br> &gt; =A0 dmd has! =A0(Fortunately it&#39;s nowhere near the sheer number in= gcc/gdc.<br> &gt; =A0 ;-))<br> &gt;<br> &gt; - Unittests were added!! Now I can feel less shameful. :-P<br> &gt;<br> &gt; - Now gdmd can handle -of, -od, and -op. However, dmd appears to be<br=


, it<br> &gt; =A0 implicitly sets -od as well. Gdmd still doesn&#39;t quite match dm= d in<br> &gt; =A0 this area. =A0One particularly problematic case is:<br> &gt;<br> &gt; =A0 Given this directory structure:<br> &gt; =A0 =A0 =A0 =A0 ./src<br> &gt; =A0 =A0 =A0 =A0 ./src/test.d<br> &gt;<br> &gt; =A0 Running dmd -ofbin/prog produces:<br> &gt; =A0 =A0 =A0 =A0 ./bin<br> &gt; =A0 =A0 =A0 =A0 ./bin/prog<br> &gt; =A0 =A0 =A0 =A0 ./prog.o =A0 =A0 =A0 =A0&lt;-- problem<br> &gt;<br> &gt; =A0 The trouble with this case is that currently gdmd always compiles = each<br> &gt; =A0 source file separately (following the behaviour of the old Perl</p=

<p>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 th= at matters ).</p> <p>&gt; =A0 script), so we can&#39;t just rename the default test.o to prog= .o. Also,<br> &gt; =A0 IME, running gdc with too many .d files at once can sometimes caus= e<br> &gt; =A0 memory problems, so doing it one at a time seems preferable.<br> &gt;</p> <p>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.<br></p> <p>The difference between single and multiple file compilation is very subt= le in gdc since the switch to LTO. </p> <p>gdc foo.d bar.d.=A0=A0 # compiled separately.<br> gdc foo.d bar.d -o exe=A0=A0 # compiled together.</p> <p>People from a dmd background I found expected the latter, and separate c= ompilation also comes with its own quirks that don&#39;t occur during singl= e compilation of all sources (the most common suggested work around for thi= s being -femit-templates, though should give the switch -fonly some lovin&#= 39; someday).</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;<br> </p> --047d7bb03d3681b4bb04e13713ce--
Jul 11 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 next sibling 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
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 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
prev sibling next sibling parent 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
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
next sibling parent "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>



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
prev sibling next sibling parent 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
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>



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 "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 next sibling parent "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
prev 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 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 next 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 "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
prev sibling next sibling parent "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
prev sibling 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 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 #!/bin/bash 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 #!/bin/bash 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