Preparing FPC 3.2.4, point out road blocks now

[ccrause]

The machinery is moving again: Freeze of fixes for 3.2.4 by 9th June

[TRon]

Does that freeze imply that the 3.2.4 release will (again) not contain a fix for #40701

I ask beforehand because it seems to be a problem for a lot of people so many questions will arise (again) when this is released without a fix for it.

[ccrause]

Does that freeze imply that the 3.2.4 release will (again) not contain a fix for #40701

That issue appears to be specific to FPC 3.3.1. If the same issue is triggered with FPC 3.2.2 or current 3.2.3 (fixes), then it is a relevant concern to this specific fixes release.

[marcov]

That issue appears to be specific to FPC 3.3.1. If the same issue is triggered with FPC 3.2.2 or current 3.2.3 (fixes), then it is a relevant concern to this specific fixes release.

Yes, that is what I understood too.

[TRon]

As far as my knowledge goes it was reported by people on the forum with the release of Lazarus 3.2 as well, and according to that same knowledge that included the Lazarus fix for that issue (the original issue was two-fold, the FPC part still open)

I would have to have a closer look to see if it (still) appears with latest Lazarus release (with 3.2.2 FPC release). Mind that as long as you do not install Lazarus in a restricted directory the issue will most probably never appear (never ran into it myself unless forced).

[wp]

As far as laz.VirtualTreeView is concerned, the issue could be avoided by rearranging the units in interface and implementation sections. This is in Laz/main (and fixes, it was too late vor 3.4), and Laz/main now compiles fine with fpc 3.3.1. (https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/3635aa304475f4f66374d723c7fedf8309c8fac8).

[TRon]

@wp, yes indeed (though in my memory it was already fixed because it was a re-introduced bug from way earlier).

fwiw you can circumvent this particular vtv issue by installing Lazarus in a directory with enough access-rights so that the fallback to the config directory does not happen.

The underlying issue is rebuilding the IDE and the compiler indicating the need for recompilation (while it shouldn't). Also easy enough to circumvent by turning off the checksum check but that is not how things are suppose to work 

What I do not know is if any of the changes in trunk that caused the behaviour are going to be present in 3.2.4 in which case the issue will persist, hence the question.

fwiw: I haven't kept a close eye to this particular issue as it was taking too long for my liking (and therefor used fixed hashes) so perhaps it has been (properly) addressed already but I haven't noticed any mention of it so far.

[PascalDragon]

What I do not know is if any of the changes in trunk that caused the behaviour are going to be present in 3.2.4 in which case the issue will persist, hence the question.

No, they're are not, because they were very invasive changes that have no place in a fixes release.

[TRon]

Thank you for clearing that up PascalDragon.

[marcov]

Also, even in trunk the rearrangement of virtualtrees is a workaround, not a fix I think?

[zeljko]

Yes, it's just workaround.

[440bx]

maybe I missed the obvious but...

what is the issue (or issues) that are holding up the release of FPC v3.2.4 ?

No matter how many times I read the posts in this thread I cannot manage to see the issue or issues responsible for the delay.

A short, concise, clear and unequivocal answer would be greatly appreciated ... thank you.

[TRon]

A short, concise, clear and unequivocal answer would be greatly appreciated ... thank you.

arm target has/had some issues that needs to be addressed before a release can happen. afaik that is the only hold-up.

[440bx]

arm target has/had some issues that needs to be addressed before a release can happen. afaik that is the only hold-up.

Thank you TRon.  At least that is clear.

[zeljko]

Is it possible to merge https://gitlab.com/freepascal.org/fpc/source/-/commit/f4cc2447a2c9b751c0c31b35dcd9b92e3fd07749 into fixes ?