[fpc-pascal] Delphi for Linux is out

[Marco van de Voort]

In our previous episode, Zo? Peterson said:

> We had to maintain both FPC and Kylix code
> in parallel for several years too, and that undoubtedly made things more
> complicated than they would have been otherwise.  I?ll keep that bias in
> mind in the future.

> > No-one has ever offered to maintain a Libc import unit. It was provided
> > only as a courtesy to Kylix devs.
> 
> That's probably because the Wiki says:
> 
> "The libc unit is deprecated, and frozen in time for Kylix compatibility,
> and won't be ported to other architectures or operating systems."

It is important to realize that the libc unit was never FPC's primary api.

It was _always_ merely a kylix compatibility unit.  Before the current set
the primary api was the "linux" unit, which was later renamed to "unix".

These units already supported *BSD before Kylix even existed.
 
> It also has a long list of other reasons why the entire idea is flawed. 
> We had a rough port to both Linux64 and Darwin32 but never tried to submit
> those changes back for that very reason.

I still think that is a good thing (abandoning unit libc). While
individual calls might be fixable, as a whole it isn't.

If a new effort was made, I'd rather have new libc.so importing units that
were fairly portable to all *nix targets.
 
>   I certainly understand that from a idealogical point of view, but
> if someone doesn?t have the time or knowledge to cover everything, it does
> make it seem like a partial patch wouldn?t be welcome.  OTOH, maybe that
> is intentional, and I can?t say it?s wrong, since it does provide a high
> barrier to expanding the scope of that unit.

Yes. Which is why at least I tried to discourage that whole idea.

It is not just ideological, merely practical. By indicating you are
accepting partial patches you risk either committing them before the other
platforms are ready and setting a bad api/precedent, or leaving the patches
to linger in mantis forever.

Better direct the efforts to something better managable.

> The only thing I can think of that would have been retroactively useful is
> if Libc.pas had included deprecated declarations with messages saying
> where the replacement units/methods are.

The libc unit has had that status since 2003-2005. Deprecated and even more
deprecated-with-messages was a much, much later feature (2.4, 2010?). There
had been only the most minimal patches for unit libc (and virtually no
indications of serious usage) for years by then.

I think a better solution would have been to support large parts of the FPC
api on top of Kylix. But when I reacted with comments like that I was
usually met with a reluctance to invest in Kylix at all. So you get a
catch-22 with still supporting kylix but not investing it, not even to
manage its legacy.