[lazarus] Delphi and FPC compatible LCL version

[cryst]

Just to weigh in on this issue. I'm currently using Delphi (5) and
Cbuilder(5) in my development, which has releases every month, and usually
mid-month as well.  To do development we use Delphi to do the internet, pdf,
and interface stuff, and cbuilder to do the calculations and data stuff. To
do this, we compile the cbuilder side into either a release (which means it
compiles the Delphi code as part of the project) or as a dll which is used
only for development of the Delphi side.

I was originally interested in Lazarus and FPC because of it's multi
platform ability. To me, making it Delphi compatible means giving me more
options. (I can go to either Delphi or FPC/Lazarus). I like that.  I ended
up ignoring the FPC for a couple of years, due to the large differences
between the compiler syntaxes. (I know you don't believe me, but I'm the one
who would have to end up re-writing everything). It would be very useful to
me if the FPC was able to compile the VCL code. Then I would be able to move
to the LCL in a gradual manner. (There is too much to do all at once, and
insure it is bug free).

Just thought you might like to hear from someone quietly rooting you on,
from the trenches.

Chris Bruner

----- Original Message ----- 
From: "Mattias Gaertner" <nc-gaertnma at netcologne.de>
To: <lazarus at miraclec.com>
Sent: Monday, November 17, 2003 11:36 AM
Subject: Re: [lazarus] Delphi and FPC compatible LCL version


> Wow indeed.
>
> That saves me a lot of time. :)
>
> Maybe a few additions:
>
> The LCL is based on the FCL and the RTL of FPC.
> At the moment, it is possible with less than a hundred IFDEFs to support
the
> Delphi units, but this will become a mess, as soon, as the LCL supports
> threads, widestrings, better localization, dynamic libs and more
platforms.
> So, in fact, the LCL is bound to the units provided by FPC.
>
> According to the mails, the main reason to support the Delphi compiler, is
> to use the LCL with existing Delphi code, which can't be compiled with
fpc.
> My question: What features are not supported by FPC 1.9, are portable and
> can be used with the LCL?
>
>
> Mattias
>
>
> > wow I seem to have missed all the fun. :)
> >
> > well here is my long winded take on the subject(not to reopen the
> > issue).
> >
> > 1.) Why should it be ported to Delphi?
> >    well several answers here mentioned,
> > a.) another compiler to test and find errors with
> > b.) closer compatibility with vcl.
> > c.) larger programming community
> > d.) well, why not its Open Source, anything should go.
> >
> > these are not bad reasons and not entirely incompatible with the goals
> > of LCL and lazarus assuming they are true/work out this way. But that
> > brings up the next subject, why not? why _shouldn't_ we accept this sort
> > of patch?
> >
> > 2.) Why shouldn't it be ported to Delphi
> >  I have heard and have several reasons I have my own where I can see why
> > not -
> > a.) The LCL is an FPC project, more specifically -
> >
> > if the LCL is a FPC project it should take
> >  advantage as much as possible of the programming
> >  advantages offered by FPC, in my opinion not only
> >  should the LCL and lazarus sources use ObjFPC as
> >  much as possible, they should make use of the
> >  extensions offered by FPC where it makes for more
> >  readable code, and where it makes for easier
> >  maintenance etc.
> >
> > Eg is in the GraphMath unit I
> >  made use of operator overloading to simplify bezier
> >  math. this is not only more readable code, it is less then
> >  1/4'th
> > of the size required in Delphi. properly ported to Delphi not only
> > ensures a larger
> >  code-base but less understandable code, if this
> >  project were always intended to work with both
> >  making this sort of sacrifice would make sense, but
> >  it was not and has not, and converting to Delphi
> >  means a step backward for something not even part
> >  of the intended goals.
> >
> > b.) porting to Delphi does _not_ ensure better VCL compatibility
> >
> > Porting to Delphi means only a few things, the LCL
> > now works with Delphi so long as you do not use the
> >  VCL at all, or change the names of all the LCL to
> >  be incompatible with VCL names so they don't
> >  conflict.
> >
> > If we wish LCL to work with Delphi properly we must
> >  change the names, to those like in kylix, so not
> >  compatible, and either do this only for the Delphi
> >  version, which means FPC LCL and Delphi LCL apps
> >  are not source compatible without ifdefs etc., or
> >  for all apps, which means old LCL apps need to be
> >  changed, and Delphi VCL apps _still_ need more
> >  modifications just of files, not to mention all
> >  controls and back-end differences ensured by the
> >  very cross-platform nature of it. Both solutions break the
> >  very
> > concept of LCL portability.
> >
> > c.) maintainability
> > if changes are kept within ifdef's this adds huge
> > overhead to the complexity of code, if it were
> > stored in includes, then due to the nature of the
> > current layout whole files will need to be
> >  duplicated for minor changes, either case adding a
> >  great deal of problems to maintainability
> >  especially to those who currently work and develop
> >  Lazarus and the LCL, but have no interest in the
> >  Delphi port for themselves,
> >
> > So either the current developers must also
> >  maintain this additional code meaning less
> > time for overall development, or they must leave it to other
> > people to upkeep, which in an open source environment is not assured,
> > and given the large amount of code currently in the LCL, it might be
> > months between times LCL even would compile with Delphi
> > anyway.
> >
> >  Basically IMO, meaning such a port cannot be very official,
> >  or
> > supported, which for the most part seems a waste of time and space for
> > the project at hand.
> >
> > Basically I think the overall complexity and problems caused outweigh
> > any small benefit gained from it. If this is wanted it should be
> > maintained by those who want it, as a set of patches against the LCL. I
> > am not against people doing this, and maybe in the process finding
> > non-compiler specific bugs, or minor inconsistencies which don't affect
> > good FPC compatibility that can be committed directly to CVS, but the
> > bulk of the changes suggested are not worth it and will cause far to
> > many headaches long term to do much good as part of the LCL, however as
> > kept as a separate set of patches, against specific versions or dates of
> > CVS, it ensures those who desire this, can get it and know it should
> > work with specific versions.
> >
> > there is more, but I think thats a good enough set of reasons why not -
> > inability to take advantage of most of the improvements FPC has to
> > offer, complex, harder to maintain, breaks consistency between apps,
> > makes porting harder.
> >
> > when it comes down to it the problem should be easy porting of Delphi
> > apps to Lazarus. Due to various issues they _cannot_ be fully
> > compatible, and moreover, often times (for instance lfm/lrs vs dfm)
> > cannot be shared, so even when a project is intended to be shared, much
> > code cannot be, trying to make as much as is possible shared is good,
> > but easy porting should be more important. if all the important feature
> > sets are available, and wizards and guides are available to simplify the
> > process, porting should be rapid and easy, even if the LCL is say only
> > 75% compatible.
> >
> > Lazarus to Delphi porting doesn't make a whole lot of sense imo, we are
> > working on an alternate IDE and backend, not a clone I don't like
> > everything in Delphi or the VCL, many things I would prefer done
> > differently, should we make Lazarus and the LCL compatible just for
> > compatiblities sake? I am more prone to lean toward compatiblity but not
> > if/when we can do it better. So it shouldn't be the focus, and when
> > patches to make more compatible don't conflict or make more complex
> > things better done other ways, great, and apart from win32 specific
> > stuff, there is no reason that if ways were found we couldn't get and
> > stay 90% compatible, but it shouldn't be the main goal, the portability,
> > ease of use, stability, and total available feature sets should be.
> >
> > Frankly, even all Delphi's are not compatible with each other. Delphi 1
> > Delphi2 Delphi3 Delphi 4 Delphi 5 Delphi 6 Delphi 7. NONE of them are
> > fully backward compatible, just mostly. A delphi 7 app can be made to
> > work with Delphi 6 with porting, but porting back further becomes more
> > and more complex to where porting to D1 is ludicrous at best. Should
> > lazarus be 100% compatible with all versions when even they aren't? When
> > the LCL can improve over D7 or earlier or whatever, for the most part it
> > should, but compatibility just for compatibility sake should never be
> > the driving reason behind the LCL.
> >
> > end ramble/rant :)
> >
> > Andrew
> >
> > On Sat, 2003-11-15 at 19:48, Florian Klaempfl wrote:
> > > Yes, I know. But: Delphi compatibility could bring the lcl to a
broader
> > > audience and at least for Kylix developers the lcl is usefull to write
> > > GTK applications. Further, a broader audience could also gather new
> > > developers for the lcl. My personal opinion is that an open source
> > > projects should accept all patches if they aren't too strange. Of
> > > course, nobody expects that the current lazarus developers spent time
> > > into keeping the lcl compilable with Delphi/Kylix. But if somebody
> > > provides patches why not incooperating them?
> > >
> > > Just an example: sometime ago, someone contributed patches to compile
> > > FPC (the compiler itself) with Delphi5. This is pretty useless because
> > > Delphi often IEs when compiling FPC or creates a non working FPC. If
the
> > >
> > > created FPC works, it's two times slower than an FPC compiled with
FPC.
> > > Nevertheless, we applied these patches. Why? Well, it's the way how
OSS
> > > development works. If a patch affects core functionality of a project,
> > > it's another story but it doesn't seem to be the case here.
> > >
> > > Of course, finally it's your decision, but just my 2 (euro) cent ;)
> >
>
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives