On 29-11-2011 18:49, Tomas Hajny wrote:
Which Delphi version would be the supposedly supported one? If this is
not explicitly defined, compilation might still fail when people using
lower Delphi versions try to compile the code. Do you really want to
track the feature set (especially for smaller parts like that certain
feature exists in Delphi but FPC extends the scope of the feature to a
wider set of cases)? I'd say that there is already enough bug reports
about FPC not eating Delphi code. Does anyone really want to start
fixing FPC also for bug reports about Delphi not eating code
compilable with FPC? If someone wants to support compilation of his
code with a specific Delphi version, can he do it without really
compiling it with Delphi (and also testing the result!) before
publishing the code anyway? Tomas
There's a documented delphi version: almost complete D7 support *by the
compiler* and by now d2006 now almost feature complete.
If you read me correct, I won't try to do any rtl related stuff. It is
sufficient to protect against obvious compiler incompatibility, macro's,
C type operators. Nothing else. Most of them are compiler switches, not
library features. Throwing a warning in these cases has real value for
me. (I am running my own rtl and libraries anyway: KOL+ system unit
replacements for fpc and delphi 3-2010).
So, no, I agree, this should not and probably can not pursue any or all
incompatibilities.
It can pursue however, to try to make life easier for people who need
both single sourced FPC and delphi code.
I do not plan to extend on $mode delphi which is documented as almost
100% Delphi7 compatible,
I am trying to restrict Delphi mode a Little further. Only on the
compiler level and only the obvious. Just like it pretends to be the
case already. $STRICTDELPHI is probably a bad name. Open for debate as I
wrote before.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
