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. 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.
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.
> No it isn't. It is roughly a superset of Delphi and TP, so also a superset
> over Borlands scheme.
It's more a subset of Delphi and the majority of TP merged to create a
Superset over Borland's shemes. This is therefore your own design, be it
unintentional or not. Let's not argue this point anymore.
> > LOL!!! I've been using Delphi since v1. This is a complete exageration.
> > Between D2 and D5 the unit changes are minor.
>
> So ansistrings, widestrings, dynamic arrays etc changes are minor?
Unless you use widestrings, nope, no difference. Unless you use dynamic
arrays, nope no diffewrence. Remember, we spoke of D3 -> D5, and D7 -> D5,
*not* D7 -> D3.
> How many differences are there inside the core units (like sysutils)
> compared to e.g. D3? What are the deviances of FPC except adding a few
extra
> units, and putting some platform dependant stuff in extra units?
Not for mainstream, regular features.
> Try to compile something from Jedi. They still support D5, but I sometimes
> wonder how long. FPC is still getting more compatible to newer Delphi's
> fast, I don't really see the problem.
The main problem with Jedi is the fast car syndrome. "My car is fast, I must
use it at full speed."
> > You should aim for D5. Most large corperations are still using D5. We
will
> > not move to D7, we are waiting for D8 for the dotNET implementation.
Even
> > then, we will likely leave some of our legacy systems in D5.
>
> This is not common IMHO. While in my surroundings there are indeed a lot
of
> people/companies that don't upgrade, I don't see a firm separation
somewhere
> between D5 and D6+.
Most people are waiting for D8 now if they are still using D5 because D6 and
D7 have been such turkeys. Two guys in a shed don't constitute enough
developers anymore, so hopefully Borland have improved this situation ;-)
> 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.
Also annoying how you are stricted with regards to assignment of pointers. I
remember that an additional cast used to be needed when setting up a
tagWNDCLASSEX for example. The lpfnWndProc field needed to be cast and
dereferenced, unlike Delphi. This made it necessary to use an ifdef for no
good reason! Maybe this is fixed now, but it was amazingly annoying. It
cropped up in other areas too.
> The only way to improve the situation is more collaborators, and/or a much
> higher users that e.g. occasionally does some work for FPC (update a
certain
> unit, make an interface etc). The situation nowadays is already much
better
> than it used to though say a few years back, on the other hand, there is a
> lot more to do nowadays too.
My main problem is that everytime I go to look at the compiler source, I
can't get it to compile, even though I can't see a reason why. I had the
BeOS port compiling fine, but I rehashed the dir structure. Maybe I'll have
another look. I want to make a plugin that uses the Delphi IDE to edit FPC
source and lets you compile from the IDE too. Maybe I'll do that sometime
soon.
Matt
_______________________________________________
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
