[fpc-devel] 134 open merge requests - is that normal?

[Tomas Hajny]

On 2026-04-07 17:20, Martin Frb via fpc-devel wrote:
> On 07/04/2026 16:21, Tomas Hajny via fpc-devel wrote:
>> On 2026-04-07 15:58, Martin Frb via fpc-devel wrote:
>>> On 07/04/2026 15:41, Martin Frb via fpc-devel wrote:
  .
  .
>>> Actually, I would think the relation between fpc src and build can be 
>>> described as n to 1
>> 
>> Not really? Most changes in fpc-build don't depend on changes in 
>> fpc-src (at least not directly) and vice versa? However, you need to 
>> have both parts up to date when building (either a release, or a 
>> snapshot, or whatever - depending on the particular branch).
> 
> Ok, then I got that part wrong. So then maybe its to adapt to changes 
> in OS, make, ....

Yes, partly (e.g. 3rd party tools and binary data needed to be included 
with FPC releases for certain targets which don't provide them 
out-of-box), target and/or Linux distro specific metadata for specific 
FPC releases (including modified makefiles for complete releases - e.g. 
including the Windows installer, Unix installation scripts, etc.), but 
it also holds release specific artifacts like associated readme.txt, 
whatsnew.txt and faq.txt, used licenses, etc. The main distinction is - 
you only need this repository when performing release building, there 
are no .pas or .pp files within this repository.


>>> - For any commit in fpc-src there is one fpc build commit that works 
>>> (others may, but one that should be used)
>>> - For any commit in fpc-build there are many commits in fpc-source 
>>> that it can be used with/for.
>> 
>> It isn't just that it wouldn't build, but that you need clearly 
>> defined combination you can refer to (should it be because you want to 
>> test building and the point of the test is having a consistent state 
>> to which the test refers to, or because you want to be able to refer 
>> to a clearly defined point in time in the bugtracker, because there 
>> _are_ some cases in which one depends on the other).
> 
> But then that is the point I made, or isn't it.
> 
> If you build FPC source SHA xxxx => then you must have FPC build => sha 
> yyyy

It isn't that you must have FPC build => sha yyyy (and it wouldn't build 
otherwise), it is that you always _should_ have the most up to date 
version of both. It's like saying that you must have FPC RTL >= SHA xxx 
when building release of FPC compiler >= SHA yyy - while that is true 
for certain versions, you simply don't want to include random (although 
technically "valid") combinations of FPC RTL and FPC compiler sources in 
the release process, because you want to be sure that two people 
building the release should always use the same combination. And if you 
want that for the release, you also want to have that when testing the 
release building process.


> But if you have sha build sha nnnn => then there are many fpc-build 
> commits that could be build with it.
> At least the fact that many otherwise identical fpc-build commits have 
> all those different fpc-build commits would strongly suggest that.

You probably have some typo there (fpc-build x fpc-build), but I hope 
that I clarified the point above.


>>> But because the submodule in the current direction, allows to specify 
>>> only one fpc-source commit as belonging to the fpc-build commit, you 
>>> artificially keep creating commits, so you can link to all the other 
>>> fpc-source commits.
>>> 
>>> And if you reverse the dependency, that should disappear. You only 
>>> need the submodule update, when it is technically required.
>> 
>> No, because you loose the consistency then. You wouldn't test RC 
>> building, etc., against a clearly defined state, and you wouldn't know 
>> what people used when they report issues.
> Sorry, but I don't follow?
> 
> If I would check out the fpc-source commit xxx tagged as RC1, then it 
> would have an exact specified  commit in the fpc-build submodule? It 
> would always be build with that, never any other?

Yes. But preferrably, you want to be able to test that already before 
tagging (remember - there are _many_ different targets and the target 
maintainers should test their building even before tagging!), and also 
after tagging (testing the release building after needed fixes coming 
from the RC testing are applied).


>>> If the dependency order is swapped, and you commit to fpc source and 
>>> it keeps building with the same fpc-build, then there is on submodule 
>>> update needed.
>> 
>> Again, during the release (and their preparations), changes are 
>> performed in both (actually, all 3 including fpc-docs) repositories 
>> and you need to keep track of the latest (most up to date) state of 
>> both / all 3.
> 
> But the time at which those changes happen, does it really matter. So 
> long as for any give source-commit there is a specific build-commit. 
> And that specific relationship can be found for the rest of time?

I'm not sure if I understand what you mean here. The point is to provide 
anybody testing the release building (or performing the release/RC 
build) with a consistent combination of all three sources for the chosen 
branch at any point in time.

Tomas