[fpc-pascal]The state of FPC (was: Synapse for FPC)

[Michael Van Canneyt]

On Thu, 24 Jul 2003, Matt Emson wrote:

> Started a new thread because this is all getting off topic from Synapse.
>
> > Opinions differ. But the IDE and parts of the compiler itself are TP.
>
> Are there any plans to change this in future development? I, for one, like
> the idea of comiling the compiler in Delphi, but TP features are no longer
> supported. They are classes as legacy, and have many bugs in D3 let alone
> D5+.
>
> > If we had a lot of hard working people, we could make a nice new set of
> > platform dependant units, and more and more TP units would become legacy.
> >
> > Do you volunteer?
>
> To create a more rational unit set? Possibly, but last time I looked at the
> way in which FPC creates units, the scheme was awfull. You used a generic
> frame and {$i xxx.inc} for the platform. This is unmaintainable imho.

On the contrary. We switched to this exactly because the opposite cannot
be maintained. 8 years of cross-platform experience.

> One
> thing I like from the Borland Source is that I can easily read it. If I was
> to think about doing this I'd insist that the inc files went and that the
> units are assembled by concatenating a PROCESSOR_PLAFFORM_UNITNAME.INF and
> PROCESSOR_PLATFORM_UNITNAME.IMP together into a unit with a tool (sed?)
> using a script. This way the units are kept seperated as you currenlty have
> them, until  realease, but at release you end up with a final unit that is
> similar in layout to Borlands.

You can simply make a preprocessor which does that if you find it fun to do.
But this doesn't change the unit structure, and gives no advantage in
maintainability at all. At most the end user finds it easier to read the
sources.

>
> It's something I'd like to do, but I have a few things that I need to finish
> first. Certainly when the PPC port is stable, I want to port it to BeOS ppc.
> This may be a juncture to thing about contributing more time.
>
> > We do in general. But 1.0.x is frozen, and we have to make adjustments for
> > the fact that we have a strict visual<-> non visual separation, and a lot
> > more platforms (and processors in the near future).
>
> I think that, so long as you break all code into chunks that exist as
> Interface and Implementation (as mentioned above) then install routie could
> construct TP, Delphi or Wang doodle units structures. The unit construction
> script (a makefile maybe? ) would simple have a rule for each unit, and be
> driven by the 'platform' you select and the 'target processor' and
> 'programming environment'. Please stop me if anyone hates this idea. This is
> what I envisioned the future structure to be though.

I think you'll have a hard time convincing the core members.
You haven't convinced me. The system as it is works well, it took us
some time to get it like that, so we're not likely to change it, just
because someone doesn't like split-up files.

When I was at borland for an interview, the first thing I asked was
support in the IDE for include files. They scratched their head, and
said they would think about it.

This is the main reason why Delphi sources are generally without include
files: because the IDE doesn't support them. Personally, I find it more
logical e.g. to have one include file per class, this is simply not
possible in Delphi.


> > I don't understand all this. Sure, FPC is lagging behind in features, but
> > "Borland got it right in many places that FPC didn't". Where does this
> come
> > from?
>
> One of the main feature that FPC does in a way I find poor is oveloading of
> proc's. Not sure if you support the Borland method now, but still annoying.

This is largely a matter of taste. In -Sd it is mandatory to use
Borland's way, so if you restrict yourself to that mode, you should
be fine.

See: We accomodate most tastes :-)

Michael.