JCL support for Linux64 compiler

[obones 0]

Hello,

 

The JEDI Code Library is a code library for Delphi that has existed for almost as long as the IDE and which has proven useful to many users along that time.

When Kylix came out, support for its Linux compiler was added to the JCL but was left dormant ever since.

 

As it turns out, Delphi now has a new Linux compiler, based on LLVM and the support provided at the time for Kylix is not enough to bring back Linux support to the JCL.

 

I am currently trying to make the JCL compile with this new Linux compiler as can be seen in the Linux64 branch here: https://github.com/project-jedi/jcl/tree/Linux64

 

As this is quite a large task for a single developer, I would appreciate some support in the form of pull requests, or simply advice on what I should be aware of.

For instance, this compiler does not support inline assembly, so I need to rewrite those methods in PUREPASCAL form but my ASM is a bit rusty.

 

Only the files from the common folder need to be tested with the Linux64 compiler, I personally have started with JclStreams as an arbitrary choice.

I have tried to keep my commits as small as possible to illustrate what kind of problems there are and how I believe they are to be fixed.

 

Many thanks for your consideration

 

Olivier

 

[Rollo62 539]

Thats very good that someone takes care of this nice peace of code,

but I'm afraid the golden days of Jcl had been gone for a while.

Meanwhile Delphi, System, RTL, RTTI has improved much, and also added their own native Linux cross-platform support.

 

What I would suggest is to check and cleanup the code a little, to find the golden nuggets that were worth to be unraveled ( I'm sure there are many ).

Who is using Jcl / Jvcl actively, who can give some hints ?

 

If Jedi would not be such a big unsorted mess I would like to look deeper into this too,
but I always have the bad feeling that it brings more overhead than it brings useful features.

 

Maybe you have some deeper insights, and you can explain what features especially should stay and which one should be separated ?

To have a general, external library that could fill some gaps of Delphi would be a good idea, in my opinion, but it should be directly VCL/FMX ready, not especially platform binded.

 

[Fr0sT.Brutal 900]

I too always paid great respect to Jedi team for such a huge code base but the lib is so monolithic that I've never used it except for some little inspirations and, of course, great header translations. Probably JVCL could make me take this move but times when I played with thousands of visual components are gone, now I'm happy with only std ones & VTV. I know plenty of people that tend to say "What, Jedi? These millions of units and stuff? Oh, forget it, I'd better write that function myself".

[obones 0]

It is not as monolithic as one may think at first. Sure, it's a big collection of files, but I'm talking about the JCL here, the class library that has NO visual components.
Inside that library, functions are sorted by families, and quite nicely at that, with no heavy dependencies all around.

 

I know full well the state of the Delphi ecosystem which explains the situation of the JCL and many other third party projects.

I also know that the JCL itself won't attract new users to Delphi, and honestly, if I was to start today a project that targets Linux, I would not use Delphi.

 

Thing is, there are users out there who have been relying on the JCL for a long time and they do not feel it to be safe to replace tried and tested code with code from Embarcadero that is almost 100% sure to behave differently on edge cases.

It is for those users that I am willing to undertake this effort, and for which I was (naively) hoping to get some support, I was not looking for a painful reminder.

[Stefan Glienke 2019]

I would approach this in a use-case driven fashion. If users want to migrate their existing code to Linux and have some issues because certain things don't compile then address those pieces until it works.

 

This might require a little more lightweight approach of the library itself - I personally have never used JCL without at some point having run the installer that produced everything for me. I remember one time where I simply wanted to use one single unit from the JCL and it ended up pulling everything and the kitchen sink (including some inc files that were not there simply because the installer hadn't generated them)

[Fr0sT.Brutal 900]

16 hours ago, obones said:

Thing is, there are users out there who have been relying on the JCL for a long time and they do not feel it to be safe to replace tried and tested code with code from Embarcadero that is almost 100% sure to behave differently on edge cases.

It is for those users that I am willing to undertake this effort

Then it will be wise to address the code they're actually using. Nevertheless, don't hesitate taking some things from current RTL (as Linux appeared in 10.x, no need in dragging 20-year-old legacy and bothering about compatibility).

[Rollo62 539]

If restructuring and modularizing the JCL would make sense, I would be interested, at least I'm doing that more or less on a daily base.

The best approach in my opinion would be to identify the domains that should be separated, and then try to unbind them from the rest of the of the JCL.

So that each domain best of all can be used standalone, without too much headaches.

 

What is missing for me is a useful discussion about those "domains", which one makes sense, which one are obsolete.

Who could start providing such list, I'm not too deep in the JCL right now ?

 

Another question is who is responsible for the JCL right now and in the future, and what about copyrights, etc. ?

Maybe the initiative should be started from the original maintainers first, or at least with their common understanding and approval.

I assume the project will end up as a complete rewrite of the JCL, so would be good to have all permission and good support to do so.

To have another good library that will be divided into many redundant forks by separate, different maintainers with different goals, makes no sense to me either.