[fpc-pascal]Synapse for FPC

[Marco van de Voort]

> > > Sure, but Borland is home for Synapse.
> > Also for FPC. See FPC as yet another Delphi version to support. If you
> > do a large Delphi product that will compile with a lot of versions, you
> > have to make adaptations also.
> 
> But is is not easy! I create my code on Delphi3, and it working on
> all higher versions without any modification!

And does it work on lower versions without any modification? Otherwise
you still don't support multiple versions.

> It is same for Kylixes!
> I have only one version of sources, and this sources working under
> Kylix with very small modifications. It is very easy!

Hmm, I actually saw a lot of ifdef linux in synapse :-) More than ever
will be needed for e.g. FPC/win32 :-)
 
> When I porting Synapse into FPC, then i find lot of incompatibilities
> between Win32FPC and LinuxFPC. For example, look to Kylix
> sysutils.pas... in FPC is not here lot of stuffs! 

Stuff that was there in D3? Don't forget that basically the _fixes_ (1.0.x)
branch delphi compability is roughly D2-D4 level! (though michael added
quite some later stuff from time to time from later 1.0.x versions)

> Some stuffs is in another units, some stuffs is missing at all. This is
> very bad situation for create programs for Delphi and FPC!
 
If it is missing, and it is not because of it being somewhat platform
dependant, it is because it is not implemented _for_ delphi mode yet.

Also keep in mind that FPC is aiming for much more platforms than Delphi
ever will. That's a strength of FPC, but no strength comes without
compromises.

FPC therefore can't work around certain issues that Borland still can. If
you want FPC (and non win32 and linux targets) you will have to think about
those issues. Adding features (including extra targets) always needs an
investment, there is no free ride, exactly like that you often need to ifdef
linux for Kylix too.

The FPC core team tries to minimalise this, but to fully take advantage of
this, you have to adapt some of the mindset, and the minimalisation of work
is meant to yield the solution that requires the least work _in the long
run_.

We have no other choice, since we all have day jobs. We can't quickly invest
a lot of time in some temporary work arounds, and sell you the next
workaround as a new version next year like Borland can.

The attitude of a 3rd party library builder towards us simply has to be
different. You are not our customer in the same way you are Borlands.

That has disadvantages (we can't make it always easy for you, e.g. if it
hampers long time development, and fully commit ourselves to every
hype-of-the-day, which is why there is no FPC.NET yet)

But there are also advantages:
- short communication lines. You talk directly to the developpers, and when
   reasonable, your fixes will be quickly absorbed.
- (useful for third party library creators) Most users use the most recent
   version, or the version before that, and usually upgrade within a year
   after a certain release. (1.0.2 usage is nihil, 1.0.4 low) Simply because
   they don't have to _buy_ the upgrade, and we don't support
    more than one or two (two if there is a major version difference) versions.
- We design FPC so that your codebase will be high quality long term, not just
   to convince you to upgrade to the next version quickly.

I think at the time we are at the second release of the 1.1 branch, (so
2.0.2 or so) most of the growth will have happened, and our lagging behind
will end for the base libraries (RTL, FCL etc). But we will have that on
a lot of systems and architectures.

Some of this might sound negative towards Borland. It isn't meant to. It's
Borlands business model, and you essentially pay them to adapt and tackle
such issues quickly.

> > I'm thinking about
> > - dividing stuff over files (units, includefiles), so that alternate
> > 	versions can be added for other os/processor/version/
> 
> I know. I only not need this yet. That is all. And redesign of this
> huge library needs a time.

Good. That's an important realisation. All my criticism is meant long-term.
I compiled a lot of Delphi stuff with FPC, mainly to test the 1.1.x compiler
compability (ICS, Decal, Jedi win32 headers, Jedi JCL, and some more), and 
the issues are always the same.
 
So try to grasp the mindset of the combination of multi-platform FPC
development and Delphi, and then try to slowly morph to that vision, simply
by making changes from time to time, and if you have to revise a particular
part of the code, revise it so that it is more compatible with FPC.

I'd aim for convergence near the time when we are starting to finalise the
1.1.x branch for release.

I wouldn't spend to much time achieving compability with 1.0.x, since a lot
will change in 1.1. However the basic principles of making a source somewhat
compiler, processor and OS agnostic and building a infrastructure for that
are universal.

> > Note that I am talking about all those defined types and constants in the
> > source, _NOT_ that you should use the actual functions in unit sockets.
> 
> When you ask me why I using my sockets definitions instead another
> one?

> Because lot of delphi versions have this definition file different!

All operating systems also have this different (and the same operating
system on a different processor usually counts as "different", you often
can't do without ifdef or special design). Think about a number of 20 here.
You can't ifdef forever, sometimes you have to revise the concept
structurally.

... Or give up everything except Linux and win32 now, and in the forseeable
future.

> It is strange, because then I must use lot of INDEFS.

.... because that would mean each item ifdef'ed another 20 times. Or at
least once for each added platform.

> Additionally Borlands files not have IPv6 stuffs, it not supporting
> Winsock2 level properly, etc.

You now only combine FPC/Linux and Kylix on one side and Delphi (+versions)
and FPC/Win32 on another side. So basically two versions with each some
additional internal ifdefs maybe. Adding any other FPC/platform means extra
ifdef and extra constants etc. (though they'll generally they'll be close to
linux, it will still be a lot, and everytime you add a platform, you have
to review and test every issue)

I'd suggest to leave the combination of win32 and Delphi intact. FPC's
win32api can better be brought in sync with Delphi's in time, there is not
much reason not to. I would move it to use includefiles to make readability
of the synsock file a bit better. 

However for the non win32 platforms the situation is different. With some
work, (needed changes to the sockets units could be absorbed back into fpc,
as much as possible), you can base all non-win32 unixy platforms on one
sockets unit. If there are ifdefs, they'll probably be on the FPC side,
or for really exotic OSes, not the avg unix.

That means three choices, "win32 combined", Kylix and "FPC sockets based 
except win32" instead of two.

That's only one more case, but a potential for a  _lot_ more possible
platforms.