Recent

Author Topic: FPC 3.2.x series branched, trunk update to 3.3.1  (Read 110609 times)

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4458
  • I like bugs.
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #150 on: March 28, 2020, 09:15:20 pm »
IMO more frequent releases with less changes would be better for new features to get adopted.
+1
Something must be done to improve the situation in future. There are bug fixes made over 3.5 years ago which are still not in a release version.
I understand the building process itself requires effort because there are so many platforms, OSs and CPUs to support. In that case the release should be built for the most popular platforms only. Users of rare and exotic platforms must continue to build from sources themselves.
Now the situation is that everybody must build from sources. Not good.
Note, developers workload with backporting bugfixes will decrease. Just push a release out, no need for a dreadful 2 year backporting exercise with merge conflicts and all.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

Otto

  • Full Member
  • ***
  • Posts: 226
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #151 on: March 28, 2020, 09:38:22 pm »
Right.
The Lazarus/FPC community could create a  Linux distribution that is the "reference" platform for lazarus/FPC development.
Otto.
« Last Edit: March 28, 2020, 09:40:37 pm by Otto »
Kind regards.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #152 on: March 28, 2020, 09:58:36 pm »
The Lazarus/FPC community could create a  Linux distribution that is the "reference" platform for lazarus/FPC development.

The closest you'll ever get to a "reference" Linux is a bare Linux Base, Debian (using deb packaging) or RedHat/Fedora (using rpm packaging). Making a Linux distro is not too difficult ... if you derive from any of those (like, say, Ubuntu does); but then you might as well go for the parent distro as your reference and avoid all the pitfalls of "BYO Linux" ;)

What we are talking here, rather, is the release frequency of FPC itself; it should be at least one release/year, even if it meant making just a "fixes" release; for example, there should have been a 3.0.6 release in 2018, and so on. Instead, we have been patiently waiting for the 3.2.0 and it seems we have quite some more waiting to do until it's "production ready".
« Last Edit: March 28, 2020, 10:01:44 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

Otto

  • Full Member
  • ***
  • Posts: 226
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #153 on: March 28, 2020, 10:33:59 pm »
Hello lucamar.

I know we're talking about the FPC release frequency.

I was hooking up to JuhaManninen's speech:
[...]I understand the building process itself requires effort because there are so many platforms, OSs and CPUs to support. In that case the release should be built for the most popular platforms only. [...]
I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.

Otto.
Kind regards.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #154 on: March 28, 2020, 10:54:24 pm »
I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.

Yeah, I guessed :)

But then you'd also have the update and maintenace of the reference platform beside the update and maintenace of FPC. And believe me, maintaining a Linux distro is no picnic; far better is to pick one of the long existing ones (like Debian) and pick that one as your "reference". As it's practically done in Lazarus where the default widgetset is GTK, which means GNOME, which (historically) means Debian.

One thing that might make it simpler for FPC is that it can get by with a base Linux, so something like Core Linux (+dev tools) would probably be enough. Of course, that's like saying that FreeDOS and a 386 box w/ 16 MiB RAM are enough for the GO32v2 target: they are, but it's a somewhat limited environment :D

Besides, FPC itself doesn't depend as much of the specific (as opposed to "generic") platform as does Lazarus so the advantage, if any, would be much less. Think again about what I said abovee: FPC can do rather well with a "standard" base Linux (+dev tools), which means it'll (or can) do well with almost any current distro.
« Last Edit: March 28, 2020, 11:01:27 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4458
  • I like bugs.
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #155 on: March 28, 2020, 11:24:49 pm »
I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.
Otto, you misunderstood the issue badly. Different Linux distributions are not the issue here. Most Linux users have a x86-64 CPU. One single FPC release build covers them all. Remember, FPC is a compiler with only few external dependencies.
Copied from Overview in https://freepascal.org/  :
"Free Pascal is a 32, 64 and 16 bit professional Pascal compiler. It can target many processor architectures: Intel x86 (including 8086), AMD64/x86-64, PowerPC, PowerPC64, SPARC, ARM, AArch64, MIPS and the JVM. Supported operating systems include Linux, FreeBSD, Haiku, Mac OS X/iOS/iPhoneSimulator/Darwin, DOS (16 and 32 bit), Win32, Win64, WinCE, OS/2, MorphOS, Nintendo GBA, Nintendo DS, Nintendo Wii, Android, AIX and AROS. Additionally, support for the Motorola 68k architecture is available in the development versions."

Maybe you confuse FPC with Lazarus / LCL which must deal with GUI libraries.
Creating a reference platform for FPC, maintained by FPC developers? Uhhh, C'mon!
What CPU would it support? What OS? Would FPC developers create a new OS? Should support for all other CPU / OS combinations be dropped?
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #156 on: March 28, 2020, 11:28:20 pm »
I understand the building process itself requires effort because there are so many platforms, OSs and CPUs to support. In that case the release should be built for the most popular platforms only.

Usually it is targets like Debian and OS X that hold up. So that will never work.

It is also not entirely static, e.g. Joost built many linux targets using docker containers this time around. He is also building RPMs for a long time, and those are usually on time. My FreeBSD was usually also on time, but with the recent LLVM transitions I have massive problems (and only FreeBSD11 will be released)

One of the big problems of FPC release engineering is that it mostly stops (aside from my merging on mostly packages/) between releases.   And people don't start when a branch is made, but only when it is getting close to release time. Gearing up, figuring out the situation and fixing problems is what causes the delay, not routine work, combined with long delays to get feedback about the state. Keep in mind that a defective compiler is next to useless.

The more parts of the project are covered by continuous maintainers that also check and use the fixes branch continuously, then something might change. Something like Lacak does with fcl-db.

Just thinking up unachievable targets won't change anything, you must also come up with a manageable path to it.

Actually release building has become better (as in less risky) over the years, but the complexity of the project has gone up and the members time has gotten less, so I understand that users sometimes get the wrong impression.
« Last Edit: March 28, 2020, 11:35:20 pm by marcov »

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #157 on: March 29, 2020, 04:54:47 am »
The more parts of the project are covered by continuous maintainers that also check and use the fixes branch continuously, then something might change. Something like Lacak does with fcl-db.

Just thinking up unachievable targets won't change anything, you must also come up with a manageable path to it.

Actually release building has become better (as in less risky) over the years, but the complexity of the project has gone up and the members time has gotten less, so I understand that users sometimes get the wrong impression.

As a user of FPC and Lazarus, I would love to see somewhat more frequent releases.

As someone who has had to manage production environments for SaaS application developers, I am familiar with the complexity of the development lifecycle even in environments that are for-profit and reasonably staffed.    And this is a volunteer project.

So, I sympathize with both parties (users and developers) and try not to be dismissive of either sets of concerns.

As a user -- especially as I am largely a hobbyiest user, with basic development needs -- I maintain patience.   And I thank the devs for their work and dedication, and wish there were a way I could afford to fund this project.

And I feel for the community as well, which is eagerly waiting for releases (especially as some folks can only use official releases).

I'm thankful for FPCupDeluxe and the ability to use the Fixes branch more easily, which I started doing last year (or late 2018), and that has been helpful for me.

Good work team, and thanks also for a vibrant community.    Hopefully more time, people, processes or tools can be brought to bear on this issue in a helpful way.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

mm7

  • Full Member
  • ***
  • Posts: 193
  • PDP-11 RSX Pascal, Turbo Pascal, Delphi, Lazarus
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #158 on: March 29, 2020, 05:02:06 am »
A rc1 will be released very shortly.   Final Release date is to be determined, but probably not that soon.

The difference between the unreleased FIXES_3_2 branch and real releases is mostly just packaging. I would simply use a FIXES3_2  snapshot if I were you.

Great! I think I'll try.

THANKS!

PS/ I read the thread... I think one of the problem is that the compiler, RTL and packages are all packaged together. May be if they were separated, at least packages, that may allow to make updates and maintenance of each part more agile?
« Last Edit: March 29, 2020, 05:18:53 am by mm7 »

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #159 on: March 29, 2020, 08:15:57 am »
mm7, just in case its helpful, two things -

Firstly, my notes for installing 3.2 on Linux (if you don't use Linux, sorry, please ignore), This was how I installed FPC 3.2.0 on a beta U20.04 VM.

Download the source zip  and the system dependent binary tar.
wget ftp://ftp.freepascal.org/pub/fpc/snapshot/fixes/x86_64-linux/fpc-3.2.0-beta.x86_64-linux.tar.gz
//Has prebuilt binaries.
wget ftp://ftp.freepascal.org/pub/fpc/snapshot/fixes/source/fpc.zip
//Has the matching fpc source.
sudo -i
mkdir -p /usr/share/fpcsrc/3.2.0
cd /usr/share/fpcsrc/
unzip /home/dbannon/Downloads/fpc.zip
mv fpc 3.2.0
ln -s 3.2.0 default
apt install binutils make gcc subversion
cd /usr
tar xzf /home/dbannon/Downloads/fpc-3.2.0-beta.x86_64-linux.tar.gz
ln -s /usr/lib/fpc/3.2.0/ppcx64 /usr/bin/ppcx64
fpcmkcfg -d basepath=/usr/lib/fpc/3.2.0 > /etc/fpc.cfg


Secondly, are you sure you cannot use libssh ? In many cases is a a problem relating to Lazarus apps looking for an older version's name, libssh.so.1.0.0 and you have, probably, libssh.so.1.1.  Easy solution is to install the development package, that will make a symlink from libssh.so.1.1 to libssh.so and Lazarus apps do look for that.  Once found, it all works.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

zamtmn

  • Hero Member
  • *****
  • Posts: 593
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #160 on: March 29, 2020, 08:26:12 am »
To remove all questions fpc team need to keep the roadmap up to date, not as it is always he only misleading. Оr don't do it at all

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #161 on: March 29, 2020, 09:06:54 am »

PS/ I read the thread... I think one of the problem is that the compiler, RTL and packages are all packaged together. May be if they were separated, at least packages, that may allow to make updates and maintenance of each part more agile?

Not really, as I said, the packages/ directory and the easier parts of the RTL are the main parts that *are* merged regularly, and is less complex.

The deeper RTL and the compiler are fairly closely linked.

Mostly the problem is stabilization of RTL and new compiler features on all targets and validating that together with adapting to changes in targets and their packaging that.

But most of that work has been done only this year, when the 3.2 branch was already 1.5 years old. As said this is not a continous process.
« Last Edit: March 29, 2020, 09:12:06 am by marcov »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #162 on: March 29, 2020, 09:12:47 am »
To remove all questions fpc team need to keep the roadmap up to date, not as it is always he only misleading. Оr don't do it at all

You can't update what you don't know

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4458
  • I like bugs.
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #163 on: March 29, 2020, 11:13:19 am »
Usually it is targets like Debian and OS X that hold up. So that will never work.

It is also not entirely static, e.g. Joost built many linux targets using docker containers this time around. He is also building RPMs for a long time, and those are usually on time. My FreeBSD was usually also on time, but with the recent LLVM transitions I have massive problems (and only FreeBSD11 will be released)
Is LLVM now a requirement? That complicates things surely.
About Unix / Linux release: I used to install FPC release using the FPC's provided install script when my distro didn't provide the latest version. It worked very well. It is more reliable than using external .deb or .rpm packages. They tend to break the package system, judging by my experience and by the number of related forum threads.
I guess the script can easily be ported to any Unix related system, regardless of CPU.
Distributions build their own packages after some SW is officially released. Arch and Manjaro do it quickly, most other distros have a longer delay, but the release announcement is the trigger always.
It means the release announcement is important even if FPC project does not provide installation packages!
It also affects Lazarus development. Lazarus trunk promises to compile with 2 most recent FPC releases. Now it means we must support ancient versions.

Stabilizing the compiler and RTL on every platform is a challenge, I understand.
I think the rules must be loosened, all platforms cannot be finished at the same time with the limited resources.

If you announced FPC 3.2 release today, Arch and Manjaro would build and provide packages within a week or so. Other distros would provide it in their next release. Many people would be happy and FPC maintainers would not need to build anything.
For Windows an installer is needed as Windows has no sophisticated installation package system.
Is an installer needed for MacOS necessarily? I don't know, I don't have a Mac.
For other platforms a simple install script suffices. Just one wish: add an uninstall option to it.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

Otto

  • Full Member
  • ***
  • Posts: 226
Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Reply #164 on: March 29, 2020, 11:18:54 am »
Hello JuhaManninen.

I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.
Otto, you misunderstood the issue badly. Different Linux distributions are not the issue here. Most Linux users have a x86-64 CPU. One single FPC release build covers them all. Remember, FPC is a compiler with only few external dependencies.
Copied from Overview in https://freepascal.org/  :
"Free Pascal is a 32, 64 and 16 bit professional Pascal compiler. It can target many processor architectures: Intel x86 (including 8086), AMD64/x86-64, PowerPC, PowerPC64, SPARC, ARM, AArch64, MIPS and the JVM. Supported operating systems include Linux, FreeBSD, Haiku, Mac OS X/iOS/iPhoneSimulator/Darwin, DOS (16 and 32 bit), Win32, Win64, WinCE, OS/2, MorphOS, Nintendo GBA, Nintendo DS, Nintendo Wii, Android, AIX and AROS. Additionally, support for the Motorola 68k architecture is available in the development versions."
[...]
A mutual misunderstanding is always possible.
It is also possible that what I have said is wrong: I certainly do not claim to be right.
I do not think I have misunderstood the thread argument, that I do not know the basic differences between the various OSs, that I do not know the differences between FPC and Lazarus/LCL; It is, however, possible that I did not express my thoughts correctly on this subject.
I will try to rephrase what was said earlier.

If many developers, especially inexperienced, had the ability to easily verify the operation of FPC using a common OS with similar configurations, it would be easier to spot bugs in the FPC. This, mainly, because there would be fewer variables to check.

Microsoft has released a virtualized development environment where both newbies and experienced programmers could have a common development environment, with the main purpose of detecting bugs. Unfortunately, I have no data to indicate whether this choice was effective or not.

Quote
[...]
Maybe you confuse FPC with Lazarus / LCL which must deal with GUI libraries.
Creating a reference platform for FPC, maintained by FPC developers? Uhhh, C'mon!
What CPU would it support? What OS? Would FPC developers create a new OS? Should support for all other CPU / OS combinations be dropped?
I have never said that support for other platforms should be removed, the purpose would be to have a test environment ready to use and already configured to be used just for this purpose.
Some Linux distributions have already provided tools that can be used to achieve what I have proposed.

As I said before mine is just a suggestion.
Kind regards.

 

TinyPortal © 2005-2018