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

[Anders F Björklund]

Philip Van Hoof wrote:

> 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 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.

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

Well, just as long as you can link a D component created with "gdc"
to a C/C++ component compiled with "gcc" - it's close enough to count ?

> 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.

I think what we could be aiming for is to include the *patches* into 
GCC, and provide the D front-end and the Phobos library as add-ons ?

> 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).

Yes, that it's the preferred solution if it works. I was (eventually) 
able to do so on Mac OS X, by bringing a few Apple changes over as 
patches to the FSF tree. For Fedora, it's about finding the patches...
(you only want the ones that affect features and binary compatibility)

> 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.

Yes, sounds like a good start... I'm also working on the other missing 
components, namely a development environment (IDE) and a user interface.
And me and my company is investing heavilly in making it more popular,
even if met with mixed success so far... But maybe one day it will be ?

> 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.

The advantage of doing a vanilla GCC/G++/GDC compiler in /opt/gdc, is 
that you don't have to rely on the package monkey of the DistroDuJour 
but that you can use one self-contained compiler package for all...

The downside is that GDC is like 3 MB, while GCC/G++/GDC is like 30M ?
(not to mention having to re-compile all the libraries you want to be 
using, just because C++ isn't link-compatible between versions, etc.)


In theory the spec file I have can be used, if the system compiler is
of a usable version (i.e. not too old like RH 7 nor too new like FC 5)

But you still need one RPM for each distro version, which is a pain...
However, if the build is able to be automated - it can be lived with ?

--anders