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

[Philip Van Hoof]

On Tue, 2006-04-18 at 17:19 +0200, Anders F Björklund wrote:

> > Okay. Mine isn't building C and C++ packages at this moment. As that
> > would conflict with the existing build environment.
> 
> Yes, you can't actually use them if you have GCC/G++ installed :-)
> Just figured I might as well package them, since it builds it anyway.

Also if you only do --enable-languages=d? I can imagine it will always
compile a c compiler, but will it also compile a c++ compiler? I noticed
you need a c++ compiler to compile gdc. That's why I added gcc-c++ as a
BuildRequires to that spec file of mine.

> > I wonder if it would be possible to get a working GDC compiler without
> > having to conflict with the existing compiler setup?

> It is, but it needs to match the system C/C++ compiler *perfectly*...
> I'm doing this on Mac, but for the RPM spec I did both that and "opt"

We can patch the sources of the gcc exactly how the distributors did it.
Would that make it match the C/C++ compiler *perfectly*?

It would be great if the installation of such a binary gdc package would
be simple and non-intrusive for the distribution.

I understand that including gdc with the mainstream gcc code isn't (yet)
an option: After reading the newsgroups, I understood there where some
licensing issues like the FSF requiring copyright reassignment? It's
really a pity issues like that make it harder for developers who'd like
to tryout gdc.

> Idea being that any "system" version of GDC would install under /usr,
> but if you need a full GCC/G++ to match it - they all go in /opt/gdc ?

Installing in /opt/gdc is a possible but not a nice solution for
'packages'. An equal nasty solution would be to install a full gcc
environment (including gdc) in for example /usr/lib/gdc/ and then create
symlinks from /usr/lib/gdc/bin to /usr/bin. 

The best solution would be, of course, to simply build against the gcc
of the distribution and try to get a perfect match (if such a perfect
match is required).

But I don't know what is really necessary and what isn't. A lot of the
patches the Fedora packagers added are related to, for example, the ada,
objc and java frontends. Another patch fixes the po files (there's ~ 18
such patches).


If I can be of any assistance with making gdc more accessible, let me
know. I'm not a compiler developer, but as I'm very interested in the D
programming language ... I'm prepared to spend some of my free time on
it ;).


My personal story is that if the language would be a little bit more
used (popular), I could more easily sell it to my employer as a usable
programming environment. Packages would be a good start.

It would also be more easy for packagers to build my softwares, if a
packaged compiler would exist. The packagers in our communities really
dislike having to compile a compiler before they can create a package of
our software. Most of the packager communities have automated package
building environments that will automatically test and compile for all
supported architectures. You don't want to require them to compile a
compiler in /opt/gdc ;-). They wont package your software.

Which is a problem for gdc adoption. But I'm willing to spend time on
getting it done. I don't want to be yet another whiner etc ... I really
want it (gdc). Like .. Really ;-)


> I posted some thoughts on this very topic earlier, in:
> http://www.digitalmars.com/d/archives/D/gnu/1561.html
> 
> I believe the "integration" problems should be rather similar,
> whether on Fedora Core or on Mac OS X ? (both patch their GCC)