Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[gidesa]

...commercial hardware projects...

I agree with you, many (all?) commercial projects are released being not perfect/unfinished.
But the fact is that Fpc compiler is not a commercial project. So it cannot be compared to that ones, nor to the commercial projects developed using same Fpc.
Free/voluntary projects, as Fpc, and commercial projects have totally different goals and priorities.
One can like or dislike, but this is.

[robert rozee]

...commercial hardware projects...

[...] many (all?) commercial projects are released being not perfect/unfinished.
But the fact is that Fpc compiler is not a commercial project. So it cannot be compared to that [...]

why can it not be compared? sure - there is no money being exchanged - but there is reputation, pride, and a sense of achievement. from the FPC consumers there is thanks given through forum discussions and folks producing their own projects making use of FPC/Lazarus.


cheers,
rob   :-)

[LV]

deja vu ? 😦

https://forum.lazarus.freepascal.org/index.php/topic,57173.msg424654.htm

[LeP]

deja vu ? 😦
https://forum.lazarus.freepascal.org/index.php/topic,57173.msg424654.htm

.....  but there is reputation, pride, .....

We are happy to announce the release of the Free Pascal Compiler version
3.0.0 "Pestering Peacock"

 

Jokes aside, I agree with @gidesa: open source projects (especially FPC and Lazarus) can't be compared (in general) to commercial ones.
This doesn't change the fact that they're useful, powerful, and can produce projects just as good as commercial ones.
However, many open source projects that compete with commercial products are generally funded by commercial companies. For example:

- Fedora (-> Red Hat);
- Ubuntu (-> Canonical);
- OpenShot Video Editor (-> OpenShot);

[PascalDragon]

sure, the FPC developers have been working for years on 'something' destined to one day become a 3.4.0 or 4.0.0 release, but besides those handful of developers, who needs this new version? FPC 3.2.2, as a compiler, seems to works just fine for many thousands of everyday users.

If it works for you, well, congrats, lucky you. But that 3.2.2 has issues for users and some even big ones is undebatable, because they were reported against that version on the bugtracker. And here both 3.2.3 (the base for the 3.2.4 release) and even more so 3.3.1 (aka main) are an improvement, even though the later has other issues currently.

Also there are users that desparately hoped for the one or other feature that main introduced, like anonymous functions and function references or the extended RTTI, especially when they're users of current Delphi versions.

Raspberry Pi Pico and ESP32 series

these are both microcontrollers; the number of people who would even attempt to use FPC to build an application for one of these would be minimal (if anyone at all would). the bulk of users are on intel hardware for Windows, Linux, legacy Mac. and just recently ARM for newer Mac.

But there nevertheless are users using them. And as mentioned elsewhere new targets and platforms are the least of the worries.

Macs using ARM chips

see:
https://sourceforge.net/projects/lazarus/files/Lazarus%20macOS%20aarch64/Lazarus%203.8/
the above suggests that there is an FPC 3.2.2 that can target aarch64 (M1+),

But that doesn't mean that it is without issues, mainly due to Apple changing things so that the compiler as it was released back then has problems.

admittedly, the RPi seems to be using FPC 3.2.3. i didn't realize there was a 3.2.3 release, or is this a 'special' just for RPi?

You're linking the Lazarus packages. They have recently packaged releases additionally with 3.2.3 or even 3.2.4-rc1 to give users the ability to test that version.

personally, i've never struck this problem. but if i did, it would be pretty easily worked around by just working with an array of bytes. or, again, am i missing something here?

The point of 440bx is that he wants to keep the headers as close as possible to the Windows headers to make it easier to be able to just use MSDN documentation or examples and map them to Pascal. And also for bitfields arrays of Byte are rather useless...

[gidesa]

Also there are users that desparately hoped for the one or other feature that main introduced, like anonymous functions and function references or the extended RTTI, especially when they're users of current Delphi versions.

Yes, there are also attributes. And all these features are in Delphi XE2 from 2012...
But compatibility of Fpc 3.3.1 is good.

[DavidL]

I've read this thread a couple of times in both interest and dismay.  All empires fall.  Most stagnate, atrophy, and rot from within.  Sadly, this appears no different as it's become too big to get out of its own way and there's no Linus-like figure to call the tune and get it back on track.  Time, as always, will tell, I guess.

[robert rozee]

I've read this thread a couple of times in both interest and dismay.  All empires fall.  Most stagnate, atrophy, and rot from within.  Sadly, this appears no different as it's become too big to get out of its own way and there's no Linus-like figure to call the tune and get it back on track.  Time, as always, will tell, I guess.

DavidL,
    have you read the below threads as well?
https://forum.lazarus.freepascal.org/index.php/topic,73405.0.html
https://forum.lazarus.freepascal.org/index.php/topic,73433.0.html

Dbannon (Davo) has been trying to interact with the Debian folks to help ensure that FPC 3.2.2 (or some 3.2.2 variation) does not get get deprecated from the Debian repositories. personally, i feel that this is a keystone to FPC's future.


the point that i have tried variously to get across is that FPC 3.2.2 and FPC main (precursor to 3.4.0 or 4.0.0) are now so far apart that they are, for many purposes, two different projects:

• FPC main has developers working on it, but mostly just adding new features, and has no clear path to any future release version;
• FPC 3.2.2 essentially does not have anyone working on it, and while being highly stable carries forward issues that will ensure it will not survive for much longer in the Linux domain.

with but a modicum of effort FPC 3.2.2 could be reworked into something that can survive. this may be an "FPC lite" that, while lacking many 'desirable' features, still works for most user needs and can integrate with Lazarus. what we now really need are some developers who are 'bug fix' and 'release ready' focused, and willing to work with the 3.2.2/3.2.3 source code towards a new 3.2.x release on a very short timeline.


cheers,
rob   :-)

[dbannon]

Dbannon (Davo) has been trying to interact with the Debian folks to help ensure that FPC 3.2.2 (or some 3.2.2 variation) does not get get deprecated from the Debian repositories. personally, i feel that this is a keystone to FPC's future.

Without reading the full thread, its late here, just want to say that a viable FPC 322 is now back in Debian Unstable. Its package #48 and all that has changed is that gtk2 is now suggested, not a dependency. Personally I don't understand the point of even suggesting it if its going to be removed from the disro but who cares ?

Lazarus is still an issue.

Davo

[robert rozee]

[...]  a viable FPC 322 is now back in Debian Unstable. Its package #48 and all that has changed is that gtk2 is now suggested, not a dependency. [...] Lazarus is still an issue.

could this not be solved by distributing Lazarus as a source-only package with a (user run) build script that checks for the presence of GTK2, Qt5, Qt6 and asks the user to select between the ones that are found to be present?

btw - is it technically possible for a GUI application to be built such that it can detect the available widget sets and just use whatever one is available? ie, dynamically load the necessary libraries at run-time using dlopen/etc.


cheers,
rob   :-)

[Fred vS]

[...]  a viable FPC 322 is now back in Debian Unstable. Its package #48 and all that has changed is that gtk2 is now suggested, not a dependency. [...] Lazarus is still an issue.

btw - is it technically possible for a GUI application to be built such that it can detect the available widget sets and use whatever one is available? ie, dynamically load the necessary libraries at run-time using dlopen/etc.

Yes, of course, it's possible (I've done it for X11 libraries), but it requires a bit of effort to convert the Pascal headers using "external" methods with the variable returned by `DynLibs.GetProcedureAddress()`.

Then, at init of the app, check which  widget sets is installed using `DynLibs.LoadLibrary()`.

[robert rozee]

[...] then, at init of the app, check which  widget sets is installed using `DynLibs.LoadLibrary()`.

hmm, so this would give us a Lazarus build that is entirely palatable to the Debian folks? admittedly, it might take a bit of work, but it sounds like it is not exactly complex work, just long and boring.

why on earth have the Lazarus developers (who do produce regular new releases) not already done this?! and once done for two widget sets, it presumably would be easy to add support for a future 3rd, etc.


cheers,
rob   :-)

[dbannon]

[...]  a viable FPC 322 is now back in Debian Unstable. Its package #48 and all that has changed is that gtk2 is now suggested, not a dependency. [...] Lazarus is still an issue.

could this not be solved by distributing Lazarus as a source-only package with a (user run) build script that checks for the presence of GTK2, Qt5, Qt6 and asks the user to select between the ones that are found to be present?

btw - is it technically possible for a GUI application to be built such that it can detect the available widget sets and just use whatever one is available? ie, dynamically load the necessary libraries at run-time using dlopen/etc.

In second case, "technically possible" ? Yes, absolutely. Practical ?  Maybe not.

The first case ? A vastly better approach, IMHO than what we do now. The Debian Lazarus Package would just install dependencies (ie libQtPas) and a script that the end user runs, in user space, that does the downloading of source, selecting an appropriate widget set, build.

Debian packages should (must?) not install things in user space, Linux is, at heart, still a multiuser system.  Users come and go. So, strict separation between user an root space. So, its a user run script. Some other larger apps do a similar thing.

So, in this model, Lazarus binaries never exist in root space. So, no issues about write protected files. The Debian Lazarus Package is small, simple, and easily maintained. Maybe several, Lazarus-Qt5, Lazarus-Qt6, Lazarus-gtk3 etc, all are really just there to pull in dependencies.

I already have a script that does much of the (user space) installing,

https://github.com/davidbannon/FPC_Laz_Install/blob/main/make-lazarus.bash

Similarly, fpcupdeluxe does a similar thing.

Davo

[vfclists]

How many FPC developers, committers and release managers are involved in this thread?

The ones I recognize are PascalDragon, Martin_fr and marcov.

The question I'm asking is whether this is the right place to have this discussion?

[440bx]

The question I'm asking is whether this is the right place to have this discussion?

Personally I believe it is because I also believe there are a number of forum members who would gladly invest their time into helping make the next release a reality.

I think part of the problem is that how to help is left rather unclear and, so far, I haven't seen a request to have the community assist.