On Tue, 21 Mar 2006, clayasaurus wrote:

> I wonder if anyone has ever seen this link? Sorry if it has been brought up before.
> 
> http://gcc.gnu.org/ml/gcc/2005-11/msg00541.html

Yup.. subject has been brought up several times.  The problem is to be integrated into the official gnu gcc source tree copyright has to be signed over to the fsf.  That's a showstopper, unfortunatly.  IMHO, that's a draconian policy, but it's RMS's right to set those policies for software under the FSF umbrella no matter how much I think it hurts/sucks.

Thankfully, building GDC out of tree like it is today is very very easy.

Later,
Brad

Brad Roberts wrote:
> On Tue, 21 Mar 2006, clayasaurus wrote:
> 
>> I wonder if anyone has ever seen this link? Sorry if it has been brought up
>> before.
>>
>> http://gcc.gnu.org/ml/gcc/2005-11/msg00541.html
> 
> Yup.. subject has been brought up several times.  The problem is to be integrated into the official gnu gcc source tree copyright has to be signed over to the fsf.  That's a showstopper, unfortunatly.  IMHO, that's a draconian policy, but it's RMS's right to set those policies for software under the FSF umbrella no matter how much I think it hurts/sucks.
> 
> Thankfully, building GDC out of tree like it is today is very very easy.
> 
> Later,
> Brad


If the synesis software license is the only thing keeping gdc from gcc integration (as the responder's post implies), then that's not much to worry about, is it?  Get GDC working with Ares and everything should be fine.  I don't think Sean Kelly allows code with that kind of license to reside in Ares.

The poster seemed to indicate that the problem was only in the license of the current runtime.

-JJR

On Tue, 21 Mar 2006, John Reimer wrote:
> Brad Roberts wrote:
> > On Tue, 21 Mar 2006, clayasaurus wrote:
> > 
> > > I wonder if anyone has ever seen this link? Sorry if it has been brought
> > > up
> > > before.
> > > 
> > > http://gcc.gnu.org/ml/gcc/2005-11/msg00541.html
> > 
> > Yup.. subject has been brought up several times.  The problem is to be integrated into the official gnu gcc source tree copyright has to be signed over to the fsf.  That's a showstopper, unfortunatly.  IMHO, that's a draconian policy, but it's RMS's right to set those policies for software under the FSF umbrella no matter how much I think it hurts/sucks.
> > 
> > Thankfully, building GDC out of tree like it is today is very very easy.
> > 
> > Later,
> > Brad
> 
> 
> If the synesis software license is the only thing keeping gdc from gcc integration (as the responder's post implies), then that's not much to worry about, is it?  Get GDC working with Ares and everything should be fine.  I don't think Sean Kelly allows code with that kind of license to reside in Ares.
> 
> The poster seemed to indicate that the problem was only in the license of the current runtime.
> 
> -JJR

He was only pointing out _a_ problem, not the only one.  The license issues do need to be worked out.  Files at issue:

./phobos/etc/c/recls/*
./phobos/etc/c/stlsoft/*
./phobos/std/loader.d
./phobos/std/mmfile.d
./phobos/std/openrj.d
./phobos/std/recls.d
./phobos/std/windows/registry.d

The first two are likely to be dropped from phobos, based on other threads elsewhere.  The rest need to be worked out still.

However, even if they are, the copyright issue remains.  Everyone who's submitted code would have to assign copyright to the fsf.  That includes, dmd, phobos, and the gdc glue layers.  So.. convince Walter first since he owns the most. ;)

Once those two issues are worked out, there's probably some smaller ones, but the road would be largely paved.

Later,
Brad

Brad Roberts wrote:
> On Tue, 21 Mar 2006, John Reimer wrote:
>> Brad Roberts wrote:
>>> On Tue, 21 Mar 2006, clayasaurus wrote:
>>>
>>>> I wonder if anyone has ever seen this link? Sorry if it has been brought
>>>> up
>>>> before.
>>>>
>>>> http://gcc.gnu.org/ml/gcc/2005-11/msg00541.html
>>> Yup.. subject has been brought up several times.  The problem is to be
>>> integrated into the official gnu gcc source tree copyright has to be signed
>>> over to the fsf.  That's a showstopper, unfortunatly.  IMHO, that's a
>>> draconian policy, but it's RMS's right to set those policies for software
>>> under the FSF umbrella no matter how much I think it hurts/sucks.
>>>
>>> Thankfully, building GDC out of tree like it is today is very very easy.
>>>
>>> Later,
>>> Brad
>>
>> If the synesis software license is the only thing keeping gdc from gcc
>> integration (as the responder's post implies), then that's not much to worry
>> about, is it?  Get GDC working with Ares and everything should be fine.  I
>> don't think Sean Kelly allows code with that kind of license to reside in
>> Ares.
>>
>> The poster seemed to indicate that the problem was only in the license of the
>> current runtime.
>>
>> -JJR
> 
> He was only pointing out _a_ problem, not the only one.  The license issues do need to be worked out.  Files at issue:
> 
> ./phobos/etc/c/recls/*
> ./phobos/etc/c/stlsoft/*
> ./phobos/std/loader.d
> ./phobos/std/mmfile.d
> ./phobos/std/openrj.d
> ./phobos/std/recls.d
> ./phobos/std/windows/registry.d
> 
> The first two are likely to be dropped from phobos, based on other threads elsewhere.  The rest need to be worked out still.

The GC code and portions of the runtime are a potential issue as well. I know that Walter has made much of this public domain, but that's different from signing the copyright over to the FSF as far as I know.

Ares is a possibility for the standard library, but I'm not terribly anxious to sign it over to the FSF either, sparse or no.  Unless they're amenable to a BSD type license?


sean

Brad Roberts wrote:
> On Tue, 21 Mar 2006, clayasaurus wrote:
> 
>> I wonder if anyone has ever seen this link? Sorry if it has been brought up
>> before.
>>
>> http://gcc.gnu.org/ml/gcc/2005-11/msg00541.html
> 
> Yup.. subject has been brought up several times.  The problem is to be integrated into the official gnu gcc source tree copyright has to be signed over to the fsf.  That's a showstopper, unfortunatly.  IMHO, that's a draconian policy, but it's RMS's right to set those policies for software under the FSF umbrella no matter how much I think it hurts/sucks.
> 
> Thankfully, building GDC out of tree like it is today is very very easy.
> 
> Later,
> Brad

Shouldn't we wait until the D compiler gets a less beta before we start worrying about that. It seems to me D is still far off from "1.0", so is it good to start trying to release to gcc or whateverelse in this state?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Tue, 21 Mar 2006 18:36:07 -0800, Brad Roberts wrote:

> On Tue, 21 Mar 2006, clayasaurus wrote:
> 
>> I wonder if anyone has ever seen this link? Sorry if it has been brought up before.
>> 
>> http://gcc.gnu.org/ml/gcc/2005-11/msg00541.html
> 
> Yup.. subject has been brought up several times.  The problem is to be integrated into the official gnu gcc source tree copyright has to be signed over to the fsf.  That's a showstopper, unfortunatly.  IMHO, that's a draconian policy, but it's RMS's right to set those policies for software under the FSF umbrella no matter how much I think it hurts/sucks.
> 
> Thankfully, building GDC out of tree like it is today is very very easy.

Yet it would be nice if it would be more easy to start using the compiler. Building it is for a lot programmers not really an option. Well, it should be but I guess most programmers are simply lazy.

I'm planning to build packages for GDC on Fedora and Debian. Not that I know a lot about packaging. It would be, however, very useful to have a build procedure or package management or apt or yum source for GDC.

Perhaps I can convince people like Dag Wieers to host such a package on his repositories? I'll talk to Dag about it. I was thinking about creating a new .spec file (rather than patching for example the gcc4.spec file of for example Fedora).

Anyway, I don't know when I'll finish this nor if I will succeed or whatever. I'm not really into packaging, it's just an itch I want to scratch.

But if somebody wants to help or maybe if somebody already did such a package, tell me ;-)


-- 
Philip Van Hoof

Philip Van Hoof wrote:

> I'm planning to build packages for GDC on Fedora and Debian. Not that I
> know a lot about packaging. It would be, however, very useful to have a
> build procedure or package management or apt or yum source for GDC.
...
> But if somebody wants to help or maybe if somebody already did such a
> package, tell me  ;-) 

Here is my RPM spec: http://www.algonet.se/~afb/d/gdc.spec
This new version has quite a few options to choose from ?

Unlike the DMD RPM, the Phobos library is included in main.
It also builds C and C++ packages, as a "side effect" to D.


When GDC gets a new home, we can host binary RPMS there.
(at least for the major distros, and the source SRPMS ?)

I'm doing Mac packages at http://gdcmac.sourceforge.net/
and there's been talk about providing MinGW packages too.

--anders

PS. I've been using this package spec since 0.10 or so...
    http://www.digitalmars.com/d/archives/D/gnu/1070.html
    http://www.digitalmars.com/d/archives/D/gnu/1073.html
    http://www.digitalmars.com/d/archives/D/gnu/1390.html
    http://www.digitalmars.com/d/archives/D/gnu/1564.html
    The spec has change a bit over time, but been useful.

On Tue, 2006-04-18 at 15:57 +0200, Anders F Björklund wrote:
> Philip Van Hoof wrote:
> 
> > I'm planning to build packages for GDC on Fedora and Debian. Not that I know a lot about packaging. It would be, however, very useful to have a build procedure or package management or apt or yum source for GDC.
> ...
> > But if somebody wants to help or maybe if somebody already did such a package, tell me  ;-)
> 
> Here is my RPM spec: http://www.algonet.se/~afb/d/gdc.spec This new version has quite a few options to choose from ?

Cute, you have one!

I was getting mine working already. It's actually compiling. Just ironing out the specifics and the file list.

http://pvanhoof.be/files/gdc.spec

I was typing this post about it:
-------- 
As the patch of gdc isn't working on the GCC sources which are available in the source GCC4 package of Fedora Core 4, I had to fix the function.h part of the patch to something like this:

-- At the bottom of the struct, they added some extra struct members, the gdc patch can't cope with that. It's a trivial fix --

[root@zeus SOURCES]# cat d/function.diff
--- function.h  2006-04-18 16:30:33.000000000 +0200
+++ function.h.new      2006-04-18 16:31:14.000000000 +0200
@@ -431,6 +431,10 @@
   /* Nonzero if code to initialize arg_pointer_save_area has been emitted.  */
   unsigned int arg_pointer_save_area_init : 1;

+  /* Nonzero if static chain is initialized by something other than
+      static_chain_incoming_rtx. */
+   unsigned int custom_static_chain : 1;
+
   /* Number of units of general registers that need saving in stdarg
      function.  What unit is depends on the backend, either it is number
      of bytes, or it can be number of registers.  */
[root@zeus SOURCES]#

I also added this line tot he setup-gcc.sh script and removed the function.h part from the gcc-4.0 patch. Of course can this part also be fixed correctly.

[root@zeus SOURCES]# cat d/setup-gcc.sh | tail -n 4
patch < d/function.diff

echo "GDC setup complete."
exit 0
[root@zeus SOURCES]#

Then I simply did something like:

[root@zeus SOURCES]# tar zcvf gdc-0.17-1.tar.gz d/

I also have the "gcc-4.0.0-20050520.tar.bz2" of the Fedora Core 4 source RPM

So that's gcc-4.0.0-20050520.tar.bz2 and gdc-0.17-1.tar.gz in /usr/src/redhat/SOURCES

Now in /usr/src/redhat/SPECS we put the attached file and then we do something like this:

rpmbuild -ba /usr/src/redhat/SPECS/gdc.spec

I'm still working on it (actually, it's compiling on my Fedora Core 4
system at this moment).

But I'm already attaching the spec file so that others can see.
----- 

So, check the URL ;-)

> Unlike the DMD RPM, the Phobos library is included in main. It also builds C and C++ packages, as a "side effect" to D.

Okay. Mine isn't building C and C++ packages at this moment. As that would conflict with the existing build environment.

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

> When GDC gets a new home, we can host binary RPMS there. (at least for the major distros, and the source SRPMS ?)

Sounds very good.

> I'm doing Mac packages at http://gdcmac.sourceforge.net/ and there's been talk about providing MinGW packages too.


Very nice. I'm very interested in all this. Thanks.


> --anders
> 
> PS. I've been using this package spec since 0.10 or so...
>      http://www.digitalmars.com/d/archives/D/gnu/1070.html
>      http://www.digitalmars.com/d/archives/D/gnu/1073.html
>      http://www.digitalmars.com/d/archives/D/gnu/1390.html
>      http://www.digitalmars.com/d/archives/D/gnu/1564.html
>      The spec has change a bit over time, but been useful.

Philip Van Hoof wrote:

> As the patch of gdc isn't working on the GCC sources which are available
> in the source GCC4 package of Fedora Core 4, 

I'm using Fedora Core 5, and it disliked GDC (as it's using GCC 4.1!)

But using GCC 3.2 (compat) as the compiler and GCC 4.0 as the basis,
I was able to bootstrap a working "opt" version of GDC there as well...

> Now in /usr/src/redhat/SPECS we put the attached file and then we do
> something like this:
> 
> rpmbuild -ba /usr/src/redhat/SPECS/gdc.spec

As a tip, you should probably be building in another directory... ?
You can set a new top directory up with macros, for a non-admin user.


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

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

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 ?


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)

--anders

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)