D being talked about at gcc.gnu.org (RPM)

Anders F Björklund afb at algonet.se
Tue Apr 18 15:25:46 PDT 2006


Philip Van Hoof wrote:

> I tried transforming your spec file into one for specifically Fedora
> Core 4. As Fedora Core 4 has a compiler (with updates installed it's
> gcc
> 4.0.2) that works with gdc.

> I failed because I'm getting this internal compiler error :(

"Almost works", I guess ? I know that 4.0.0 threw some fits,
but 4.0.1 has been working OK for the Mac builds at least...

I'll give your package a spin in a virtual FC4 environment, later.

>> I believe that GDC shares the exception handling with the GNU C++
>> code ?
>> It also used to share the GC with the GNU Java implementation,
>> earlier.
>
> I didn't have to enable the c and c++ languages for getting gdc
> compiled. As I'm trying to build for the installed gcc compiler I'm
> trying not to require building the c and c++ compiler.

You might be right, I've just used "c,c++,d" out of old habit.
I remember that it used to add the C++ automagically, though ?

> Right. Sounds like the best solution. I wonder whether both the GCC
> developers and the authors of the GDC patches are interested in
> cooperating here? For example, are the authors of the GDC patches
> interested in reassigning the copyright to the FSF? And is the FSF
> interested in maintaining the changes?

AFAIK, the GDC patches are written by David Friedman and under
GPL with the copyright assigned over to the FSF already... ?

> Existing development environments can be reused. Creating a ctags-like
> (dtags) for d isn't going to be very hard and would enable things like
> code completion on for example Anjuta. I think the code completion of
> MonoDevelop uses some specific Mono/C# things (so that one probably
> ain't an option).

Definitely, I am using "Code::Blocks" (a wxWidgets-based environment)
and of course Xcode when not requiring any cross-platform or openness.

> And then you have debugger integration, of course. I don't know how
> hard
> that would be.

Using GDB for debugging, as it is integrated with the tools above.
However, GDB does need a little patching to understand D mangling.

> Integration with autotools (like, m4 macro's for detecting the compiler
> and setting compiler flags correctly) might also be important. Or
> create
> a dant (like nant and ant but then for d).

I think you'll find that "Build" has assumed the role of that tool ?
I'm still using Makefiles, but that's a whole other story really...

--anders




More information about the D.gnu mailing list