This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GNU Pascal branch


Steven Bosscher wrote:

> The fact is, that the GNU Pascal crew did not want integration with
> gcc the last time this was discussed. GCC, the project, can not just
> suck in every front end out there if the maintainers of that front end
> do not want that.

Not "did not want integration". At leat I personally would support
integration very much. But there are practical problems:

1) When gcc releases version n gcc development works with version n+1.
   At the same time gpc developers typically work with gcc version n-1.
   So, there is substantial work involved to update gpc from gcc version n-1
   to gcc version n+1
2) Adjusting gpc development model. In particular, gpc uses rather short
   feedback loop: new features are released (as alphas) when they are ready.
   This is possible because gpc uses stable backend, so that users are
   exposed only to front end bugs. With development backends there is a
   danger that normal user will try new front end features only after
   full gcc release.
3) gcc develops in lockstep, which requires constant attention from
   maintainers. It is clear if such attention will be available. I
   must say that in last few years there were frequenty weeks in which
   I had no time for gpc work and even some such months.

Also, I have problems with "all or nothing" attitude to integration.
gpc is a mature front and to keep comunity alive it has to regularly
deliver bug fixes and enhancements. Realistically, succesfull integration
started when gcc development version is n+1 can deliver stable gpc
first in version n+2 (n+1 version almost surely will contain serious bugs).
Which means 2-3 years after starting integration. 2-3 years without
a stable release may disintegrate the gpc comunity. Also, there is
a risk that integration will just not work (if in tree gpc turns out
to be too buggy gcc developers may just skip testing it resulting in
even more bit-rot).

So, please understand that I do not want to drop work on all-backend
gpc before success of gpc tied to current backend is clear. And since
I was multiple time assured that all-backend gpc is inacceptable in
gcc tree I have tried to update out of tree gpc to support current 
development version of gcc. Since gcc is a moving target that turned
out to require more effort that I can spent on gpc.

Finally, coming to original topic: I do not know if Adrian's idea
is a good one. But I think that his intention was to bring gcc
and gpc development closer together with integration as an ultimate
goal.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]