| 1 |
Sorry, did not get back to this earlier. |
| 2 |
|
| 3 |
On Saturday 21 August 2004 07:47, Chris White wrote: |
| 4 |
> | BTW, there is gpc as well ;) , which is gcc based and is striving |
| 5 |
> | to be as much standards compliantas possible (Standard Pascal, Extended |
| 6 |
>pascal and few more recent additions). |
| 7 |
> |
| 8 |
> The actual reason in my choosing fpc over gpc is that it has a lot |
| 9 |
> more as far as extensions ( gtk, opengl, mysql, etc. ), and also |
| 10 |
> contains a lot of the Borland Delphi class units. This, if done |
| 11 |
Well, my first reaction was "shouldn't we just have both and let the user |
| 12 |
decide?", but then I was your proposal of virtuals. So I take it this is not |
| 13 |
really an "either or" what you mean here :). |
| 14 |
|
| 15 |
|
| 16 |
> Once again, I am also taking into consideration the need for a large |
| 17 |
> number of pascal oriented packages before I go off doing this. As far |
| 18 |
> as herd an maintainership, I'm still waiting for more herd members |
| 19 |
> before I run off and do that. I'd rather be prepared with a good |
| 20 |
> number of devs in the pascal herd, then jump in solo and watch the |
| 21 |
> fireworks fly as I try and handle other stuff. |
| 22 |
Well, this is a nice language, but it has a small community and not that many |
| 23 |
packages, just like many other "alternative" languages which we have at lease |
| 24 |
a few already. I don't think large herd is really necessary here. For such |
| 25 |
languages we usually have a simple formula: 1 active dev, one fallback dev |
| 26 |
(who oftentimes is a former trainer of an active dev :)) which seems to work |
| 27 |
fine for the most of these. One possible exception is Ada, - no its not dead, |
| 28 |
on the contrary its pretty active :). But even there I think its reasonable, |
| 29 |
as this is a comparatively low profile language - meaning not that many |
| 30 |
users. So, in short, I think standard 1 active/1 fallback dev should work |
| 31 |
reasonable for Pascal as well. |
| 32 |
|
| 33 |
|
| 34 |
> On another note: |
| 35 |
> |
| 36 |
> ~ Since there is fpc, fpc-source, and gpc, I'd like to also propose |
| 37 |
> a virtual/pascal for users that want a choice as to which pascal |
| 38 |
> compiler they're using. The users would have the choice of: |
| 39 |
Hm, I am not sure this really provides much benefit in this case. |
| 40 |
|
| 41 |
1. We are talking about a collection of compilers here, i.e. not services or |
| 42 |
libs. Users will have to actively pick and use what they want anyway. There |
| 43 |
does not seem to be a need for "transparent selection" support here. |
| 44 |
|
| 45 |
2. Still, if there were some packages that could be compiled by either one or |
| 46 |
another, than that would be sensible. However gpc and fpc are not really that |
| 47 |
compatible. In fact they both support a small common core (Standard Pascal), |
| 48 |
but then they provide support for a different extended dialects. Although gpc |
| 49 |
seems to be providing some of the Turbo Pascal features (no Delphi and some |
| 50 |
but IIRC not quite all Borland Pascal extensions). Still, considering that |
| 51 |
the packages that were mentioned were mostly dialect specific, I don't think |
| 52 |
a virtual makes that much sense here, as most of dependant packages will have |
| 53 |
to depend on a particular compiler anyway. |
| 54 |
|
| 55 |
George |
| 56 |
|
| 57 |
|
| 58 |
-- |
| 59 |
gentoo-dev@g.o mailing list |
Archives