Matthias Klose wrote:
CBFalconer writes:
Great. Now if gcc will only settle down :-)
I don't know if GCC will ever settle down. They'll keep making advances and new versions, and that's a good thing, isn't it? :-)
How far is the whole system now from full inclusion in gcc and simtel distribution?
major new chunks of code are added only on the HEAD branch, if it's in stage 1 of the release schedule (http://gcc.gnu.org/develop.html).
[...]
In the past, there has been lack of interest, lack of resources and IIRC some disappointment how or if at all patches are getting merged into gcc.
So if this merge will ever happen, someone has to bite the bullet to work on the unstable gcc ...
Let's not forget that there are some issues to be solved before this should happen. The following are only the major points that come to my mind right now. I may be missing some, and there are some smaller points as well:
- First of all, get the gcc-3 port stable. (FTR, within a few days before the last alpha, I found 4 memory management related bugs. I fixed them before the release, but on the basis of any reasonable statistics one should expect to find some more in the nearer future.)
- Fix the debug info. (Waldek is working on that ...)
- Clean up the backend patches. Some parts of them are related to the debug info problems, and may be kludges, some more are also debatable, others need some cleanups. I could well understand the GCC developers rejecting such patches, and I don't think it would be a good idea to put bad or dubious patches in GCC now and fix them later.
- Remove automake. This is a necessity for getting the compiler driver in synch (or even close to) that of the C compiler (and all other languages, AFAIK). Of course, this means that the replacement (gp) has to be finished before. If we want to do this well, this means at least going through several betas and probably a number of changes until it is satisfactory for all needs.
- Dropping the gcc-2 support. Of course, the GCC developers won't want to put in code for older GCC versions (even if conditional) in the current code. But this means, either keep two GPC source trees, one with and one without the gcc-2 conditionals (and that means, someone will have to maintain them, since I certainly won't do that; and I can tell you from experience with smaller "divergences" that it will be a boring, error-prone and generally distasteful job ;-), or to wait until gcc-2 support can be removed from GPC at all in good conscience (i.e., in a regular release cycle, like getting gcc-3 support stable in our tests, ask everyone to try it, deprecate gcc-2 support, have a major GPC release with gcc-3 support preferred and gcc-2 support deprecated, and if then no major problems appear, drop gcc-2 support).
Of course, if you really want to, you can "bite the bullet" and try integration right now. But I'm quite sure it will be much more work in total than is doing it in the proper order, and it will be technically dubious solutions (both from the GCC and the GPC viewpoint, in different areas).
OTOH, I don't see any big advantage in hurrying it. It may be easier for distribution makers (so I see your POV, Matthias), but then again, I suppose you have your build scripts in place for the current situation, and changing them to a cleaner (in this regard) style now or later doesn't make a big difference. I don't know about the "simtel distribution" Chuck mentioned -- it's no problem today to make distributions in any form (in source, if wanted, including the GCC sources, already patched possibly; sure, the archive would be a little bigger, some 15 MB instead of 2 MB, but from my impression, most Internet users won't even notice the diffrence today ;-).
Actually I wonder where this "panic" about gcc integration comes from. Since some time, I keep hearing these requests every other week. GPC has been developed for years without such an integration, and I doubt it would have been essentially better if it was integrated -- maybe even worse; currently, when there are severe backend problems (such as the `goto' bug in 2.95 on Solaris/Sparc), there is the recourse to try another GCC version; if it was integrated and tied to one GCC version, we'd depend on that version ...
Finally, if all that doesn't convince you, I'll put it in a more selfish way. The main reason why I do GPC development is that I also use GPC myself, and it's both useful and interesting to improve the tools I'm using. GCC integration doesn't provide any direct advantage to my work using GPC, so I don't feel like putting any unnecessary work in it (which would be caused by hurrying it).
So, everyone who wants to actually help the GCC integration, just pick your job from the list above (or another one I may have missed). So far only Waldek (with the "port" for gcc-3) and Eike (with the manual license change to FDL, which was another requirement) have done so (and I have done some things WRT the Makefiles and in the code which I found also useful independently of the GCC integration ;-).
Frank