[fpc-pascal]Kylix and M68k Port
Marco van de Voort
marcov at stack.nl
Wed Nov 29 15:55:33 CET 2000
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi there everyone,
> Two things then...
> Is Kylix the Free Pascal killer??
How could it? Since the Core team does the bulk of the work, the core team
would have to quit? (even if I give you all arguments below!)
And for the core team, the being free vs open sourcing argument probably is
enough already to continue.
> It could well be!!!! I've seen it, and I've
> seen it working!! I was present this Monday/Tuesday (27-28th Nov. 2000) at a
> lecture session given by Charlie Calvert (ex-Borland R&D manager) on Linux and
> Kylix. Kylix looks to be a Free Pascal Killer - no offence to you all. Why?
No offence, but I think it will strengthen the pascal platform as a whole,
and draw more users to all Pascal projects. Free, Open Source or
> I can think of a few reasons:
> 1. it has the might of Borland behind it - and believe me that alone is worth
> its weight in gold.
Sure. But still that is also its weakness. As long as sources aren't open,
you are limited to the compiler as Inprise/Borland/whatever gives it to you.
> 2. It has the IDE lacking from FPC - full RAD, basically Delphi on Linux.
Which has to be bought.
> 3. It has a command line complier, that will possibly/maybe be released for
> free (Like C++ Builder command line compiler.) This is a big maybe, but not
> to be ruled out.
We have heard signals like that before (and also about a possibility
to develop open source programs with the GUI (read what about CLX!?!)
Seeing is believing, promising is nothing.
> 4. Cross platform support. CLX.. the Cross platform component library kicks
That still has to be proved, but knowing Borland I'm not afraid of a failure
in that field.
However for the free standalone compiler to be usefull, (parts of) CLX have
to be free too. I'm curious.
Also FPC is multi-platform too, and more targets too. And I'm still not
convinced how deployable Kylix is on Linux (read on arbritaty Linux
installation, not a prepped 6.2)
The rumours about the beta's only being able to run on certain distributions
have strengthened that believe.
> 5. There is talk of porting the back end to other processors (Alpha, MIPS etc)
So is FPC, but at least FPC already has m68k, though it is outdated, and you
can see that progress is being made (in the 1.1 source tree)
> This is not necissarily fantasy either - Charlie Calvert said that if they
> could get it to run on Linux, that was half the battle - the rest was much
> less work, and therefore feasable.
That is marketing speach. A different processor is totally different from a
different OS. And if it was all that easy, they at least would have shown a
demo from other platforms (either OS or processor).
The FreeBSD port of FPC was done by me, without any prior C knowledge, and
virtually none Unix programming knowledge, and it
showed signs of life after about 50 hours work, most of it reading into
FreeBSD. After 70 hours it could compile itself, and link to shared
Why hasn't one Inprise enigineer in a hobby project or so ported it to
FreeBSD? Would make a great demo, nice marketing/press etc, at virtually
Apparantly it isn't that simple..........
> He didn't make any commitment as to
> whether it would happen though ;) If you read between the lines you felt
> that it would.
I think nothing will happen on that front until Kylix turns out to be a
commercial success. And even then, the financial branch will have to give
> What do you all think??
It might eat of some of the users, specially the GUI ones. But on the other
hand, it could draw large masses to Pascal-on-unix of which we would get our
fair share, even if they only use FPC next to Kylix. I'm not worried, and
wouldn't be surprised if Kylix would even strengthen FPC, both when it is a
success or failure. :-)
> Two interesting things came out of the talk:
> 1. Charlie Calvert demonstrated how the RPM worked by installing and then removing
> the RPM for Free Pascal!!!! (It must be noted that it was version 0.99x, so
> don't assume he is a regular user of it.)
The fact that he actually worries about it, and thinks that it is ncessary
to make such a demonstration says enough.
> 2. I remember people were talking about porting FPC to BEOS, but didn't know
> how to get FPC calling BEOS C++ structures.. I can tell you how Borland did
> it with QT.. they wrapped the entire library with C functions (a bit like an
> API) and added a mechanism for tracking Handles (ie references to C++ classes.)
> Don't know if that helps anybody. Apparrently they wrote a Perl script to automate
> the process.
We never got the patches for the BEOS support, and Be seems to be phasing
BeOS out. The C-classes support is being worked on, but couldn't be on a
short way. We want to do it well, not by some minor tricks.
Interoperability and linking with gcc has always been a top-priority, and
will be, not only for our libs, but also for our users (and dirty script
tricks don't help with that). Not only for C, but in the future also for
More information about the fpc-pascal