[lazarus] Delphi and FPC compatible LCL version

[Mattias Gaertner]

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 ;)
>