Hi,

On Mon, 2012-10-22 at 10:55 -0700, H. S. Teoh wrote:
[…]
> I've been using Russel's new D tooling to great effect -- it has been working quite well with dmd. However, I'm wondering if there's a way to make it work correctly for gdc (which uses gcc-style command-line syntax)? Currently, it tries to run gdc with dmd-style syntax, which causes object files to be wrongly named (-offilename.o gets interpreted as -o ffilename.o by gdc).

Uuurrr... the gdc tool should use GCC standard options, and indeed fail in DMD/GDMD/LDC style options.  If this is not the case we should raise a bug report, create a unit test fail and add it into the code base.

> A temporary workaround is to use gdmd, of course, but I'd like to be able to access the gcc-style gdc-specific options for my builds.
[…]

I have to admit to not having tested GDC so much as it isn't 2.060 compatible as yet, and LDC is, so I am using the ldc tool for the moment.

Thanks.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 22-10-2012 20:03, Russel Winder wrote:
> Hi,
>
> On Mon, 2012-10-22 at 10:55 -0700, H. S. Teoh wrote:
> […]
>> I've been using Russel's new D tooling to great effect -- it has been
>> working quite well with dmd. However, I'm wondering if there's a way to
>> make it work correctly for gdc (which uses gcc-style command-line
>> syntax)? Currently, it tries to run gdc with dmd-style syntax, which
>> causes object files to be wrongly named (-offilename.o gets interpreted
>> as -o ffilename.o by gdc).
>
> Uuurrr... the gdc tool should use GCC standard options, and indeed fail
> in DMD/GDMD/LDC style options.  If this is not the case we should raise
> a bug report, create a unit test fail and add it into the code base.
>
>> A temporary workaround is to use gdmd, of course, but I'd like to be
>> able to access the gcc-style gdc-specific options for my builds.
> […]
>
> I have to admit to not having tested GDC so much as it isn't 2.060
> compatible as yet, and LDC is, so I am using the ldc tool for the
> moment.
>
> Thanks.
>

It is, and has been for months.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Mon, Oct 22, 2012 at 07:03:03PM +0100, Russel Winder wrote:
> Hi,
> 
> On Mon, 2012-10-22 at 10:55 -0700, H. S. Teoh wrote:
> […]
> > I've been using Russel's new D tooling to great effect -- it has been working quite well with dmd. However, I'm wondering if there's a way to make it work correctly for gdc (which uses gcc-style command-line syntax)? Currently, it tries to run gdc with dmd-style syntax, which causes object files to be wrongly named (-offilename.o gets interpreted as -o ffilename.o by gdc).
> 
> Uuurrr... the gdc tool should use GCC standard options, and indeed fail in DMD/GDMD/LDC style options.  If this is not the case we should raise a bug report, create a unit test fail and add it into the code base.

Hmm. How does it determine which tool to use? I currently have gdc on a non-standard path, so my environment looks like:

	env = Environment(
		DC = '/usr/src/d/gdcroot/bin/gdc',
		DFLAGS = ['-O', '-g', '-funittest']
	)

But it is still using dmd-style options on the command line. Is there some other setting that I need to put in to specifically tell it to use the GDC tool?


> > A temporary workaround is to use gdmd, of course, but I'd like to be able to access the gcc-style gdc-specific options for my builds.
> […]
> 
> I have to admit to not having tested GDC so much as it isn't 2.060 compatible as yet, and LDC is, so I am using the ldc tool for the moment.
[...]

I've managed to build the gcc-4.7 git branch of GDC, which supports 2.059 (at least), so I've been able to test it on my newer code which uses some new Phobos features introduced in 2.059. I might try GDC's git master with gcc-4.8 sometime, now that I figured out how to make things work on my machine (GCC's build system is extremely fragile and a nightmare to debug when something goes wrong) -- it should support 2.060.


T

-- 
I'm still trying to find a pun for "punishment"...

On Mon, 2012-10-22 at 20:14 +0200, Alex Rønne Petersen wrote: […]
> It is, and has been for months.

I am guessing you are saying that upstream GDC is now 2.060 compliant?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 22-10-2012 21:11, Russel Winder wrote:
> On Mon, 2012-10-22 at 20:14 +0200, Alex Rønne Petersen wrote:
> […]
>> It is, and has been for months.
>
> I am guessing you are saying that upstream GDC is now 2.060 compliant?
>

Yes, as in: http://www.github.com/D-Programming-GDC/GDC

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote:
> It is, and has been for months.

The upstream source is up to date, but there are no packaged versions that I'm aware of and building it from source on a Debian/Ubuntu system has proven somewhat tricky (not just for me, see current d.gnu discussion).

Not demanding a solution, just saying. :-)

On Mon, 2012-10-22 at 11:23 -0700, H. S. Teoh wrote:
[…]
> Hmm. How does it determine which tool to use? I currently have gdc on a non-standard path, so my environment looks like:
> 
> 	env = Environment(
> 		DC = '/usr/src/d/gdcroot/bin/gdc',
> 		DFLAGS = ['-O', '-g', '-funittest']
> 	)
> 
> But it is still using dmd-style options on the command line. Is there some other setting that I need to put in to specifically tell it to use the GDC tool?

There are now three tools: dmd, gdc, and ldc. Currently with the above it looks like you are using the dmd tool and replacing the dmd with gdc.

There is not yet a d tool which tries a specific sequence according to some priority.  I couldn't decide on a Windows/OS X/Linux best priority order for DMD, GDC and LDC so I ran away form trying to implement it. This needs doing.

[…]
> I've managed to build the gcc-4.7 git branch of GDC, which supports 2.059 (at least), so I've been able to test it on my newer code which uses some new Phobos features introduced in 2.059. I might try GDC's git master with gcc-4.8 sometime, now that I figured out how to make things work on my machine (GCC's build system is extremely fragile and a nightmare to debug when something goes wrong) -- it should support 2.060.

I build LDC from it's repository, but I have not tried this approach with GCC and hence GDC. I guess I am waiting for GDC to be in GCC 4.8 and for that to be in Debian and/or Fedora.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, Oct 22, 2012 at 09:15:01PM +0200, Joseph Rushton Wakeling wrote:
> On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote:
> >It is, and has been for months.
> 
> The upstream source is up to date, but there are no packaged versions that I'm aware of and building it from source on a Debian/Ubuntu system has proven somewhat tricky (not just for me, see current d.gnu discussion).
> 
> Not demanding a solution, just saying. :-)

I've managed to build git GDC on Debian unstable (64-bit), and have just
added the instructions to:

	http://gdcproject.org/wiki/Installation

I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in the update-gcc.sh script, so your best bet is to checkout my fixed fork:

	https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix

I've submitted a pull request for the fork, but that was only today, so it probably won't get committed until a bit later.

If you want, I can send you the build script I have, that contains all
the commands (well, hopefully all) to unpack, patch, and build the
Debian GCC sources (patched with GDC, of course). If all goes well, it
should provide you with a working GDC. :)

This is only the gdc-4.7 branch, though; git master isn't building on my system because the gcc build script mistakes Walter's pathological naming of C++ source files with a .c extension for actual C code, which causes it to invoke the wrong compiler and produce reams and reams of compile errors before dying miserably. I'm still trying to figure out how to fix this.

(P.S. GCC's build system seriously needs a major overhaul. It's extremely fragile and completely unfriendly when it comes to telling you what the problem is when it fails. The error message is often faaaar away from the real source of the problem, and often has no indication whatsoever as to what the nature of the real problem is. I spent at least 2 whole days fighting with it before I figured out how to pacify it enough for the build to succeed. I wouldn't wish this experience on anyone.)


T

-- 
It's bad luck to be superstitious. -- YHL

On Mon, Oct 22, 2012 at 08:15:13PM +0100, Russel Winder wrote:
> On Mon, 2012-10-22 at 11:23 -0700, H. S. Teoh wrote:
> […]
> > Hmm. How does it determine which tool to use? I currently have gdc on a non-standard path, so my environment looks like:
> > 
> > 	env = Environment(
> > 		DC = '/usr/src/d/gdcroot/bin/gdc',
> > 		DFLAGS = ['-O', '-g', '-funittest']
> > 	)
> > 
> > But it is still using dmd-style options on the command line. Is there some other setting that I need to put in to specifically tell it to use the GDC tool?
> 
> There are now three tools: dmd, gdc, and ldc. Currently with the above it looks like you are using the dmd tool and replacing the dmd with gdc.

Does it use the dmd tool by default? How do I select the gdc tool instead? I tried env.Append(tools = 'gdc') but it didn't make any difference.


> There is not yet a d tool which tries a specific sequence according to some priority.  I couldn't decide on a Windows/OS X/Linux best priority order for DMD, GDC and LDC so I ran away form trying to implement it.  This needs doing.

If there's an easy way to select which tool to use, then it's good enough for me. Having a tool that tries to guess what you want usually ends up doing the wrong thing, especially since I have both compilers installed and often switch between them in different projects for testing, comparison, profiling, etc., purposes.


[…]
> > I've managed to build the gcc-4.7 git branch of GDC, which supports 2.059 (at least), so I've been able to test it on my newer code which uses some new Phobos features introduced in 2.059. I might try GDC's git master with gcc-4.8 sometime, now that I figured out how to make things work on my machine (GCC's build system is extremely fragile and a nightmare to debug when something goes wrong) -- it should support 2.060.
> 
> I build LDC from it's repository, but I have not tried this approach with GCC and hence GDC. I guess I am waiting for GDC to be in GCC 4.8 and for that to be in Debian and/or Fedora.
[...]

I'm going to take a shot at building a .deb for the latest git gdc-4.7 branch, which AFAIK should support at least 2.059 (and maybe 2.060?). It's probably non-trivial, as the debian gcc build scripts are a tangled labyrinth I've yet to unravel. :)


T

-- 
If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen

On 22-10-2012 21:41, H. S. Teoh wrote:
> On Mon, Oct 22, 2012 at 09:15:01PM +0200, Joseph Rushton Wakeling wrote:
>> On 10/22/2012 08:14 PM, Alex Rønne Petersen wrote:
>>> It is, and has been for months.
>>
>> The upstream source is up to date, but there are no packaged
>> versions that I'm aware of and building it from source on a
>> Debian/Ubuntu system has proven somewhat tricky (not just for me,
>> see current d.gnu discussion).
>>
>> Not demanding a solution, just saying. :-)
>
> I've managed to build git GDC on Debian unstable (64-bit), and have just
> added the instructions to:
>
> 	http://gdcproject.org/wiki/Installation
>
> I used the gdc-4.7 branch of GDC git, which unfortunately has a bug in
> the update-gcc.sh script, so your best bet is to checkout my fixed fork:
>
> 	https://github.com/quickfur/GDC/tree/gdc-4.7-update-fix
>
> I've submitted a pull request for the fork, but that was only today, so
> it probably won't get committed until a bit later.
>
> If you want, I can send you the build script I have, that contains all
> the commands (well, hopefully all) to unpack, patch, and build the
> Debian GCC sources (patched with GDC, of course). If all goes well, it
> should provide you with a working GDC. :)
>
> This is only the gdc-4.7 branch, though; git master isn't building on my
> system because the gcc build script mistakes Walter's pathological
> naming of C++ source files with a .c extension for actual C code, which
> causes it to invoke the wrong compiler and produce reams and reams of
> compile errors before dying miserably. I'm still trying to figure out
> how to fix this.

Might want to poke Iain about this. Sounds like a missing -x c++.

>
> (P.S. GCC's build system seriously needs a major overhaul. It's
> extremely fragile and completely unfriendly when it comes to telling you
> what the problem is when it fails. The error message is often faaaar
> away from the real source of the problem, and often has no indication
> whatsoever as to what the nature of the real problem is. I spent at
> least 2 whole days fighting with it before I figured out how to pacify
> it enough for the build to succeed. I wouldn't wish this experience on
> anyone.)

Unfortunately, one does not simply "overhaul" the GCC build system. It consists of thousands upon thousands of lines of logic to configure, build, and test GCC for all sorts of obscure scenarios (have you ever done a Canadian cross build of GCC?), most of which other build systems couldn't possibly get right.

>
>
> T
>


-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org