On 07/04/2026 18:03, Tomas Hajny via fpc-devel wrote:
- 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.
Ok, but then you could update the submodule (with either being the main
and the other the sub module) just before that time... Currently it is
done several times a day. I would guess there aren't release related
works or testing on the main branch at current?
And so then, right now (on the main branch) would apply to use the
latest of both. Anyone can just check them out independently (or force
their submodule locally)?
So why is that flood of "Update" commits happening.
----------------------
Mind, given the just keep the top commits together updating, even if it
isn't currently in release...
Then yes, if you switched you would have similar commits in fpc-src.
Except the last real commit on fpc-build is from February. So outside
release cycles (and for the main branch, that would be always), that
would mean one "update" commit every couple of weeks?
During releases, on fixes I take your word it would be more frequent.
Still, would it hit 3 a day, almost every day?
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.
The question is, how to you find the matching pair...
Well for a release it is easy => you go to the tag.
The tag in fpc-build will be conveniently set such as it gets you the
correct fpc-src too.
Of course then, if you go by tag, you could just have the same tag in
both repo, and you would not need submodule relations...
But if you say, you tested with fpc-src ABC123 => and you ask someone
else to test with the same...
How does that work, they can't just check out that commit, they need the
fpc-build commit that is linked to it.
So they need to go to fpc build. They need to search the fpc build
commit that will check out fpc-src ABC123....
Or (probably?) you never say, please test fpc-src ABC123 => instead you
say please test fpc-build FDE321.
Is that more convenient to do all work based on the fpc-build commit?
I mean currently yes, but if the relation was the other way round, if
you could say
Please test with fpc-src ABC123 => and switching to that would load
fpc-build FDE321 as submodule?
Would that be worse?
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).
Yes, but see above. If the dependency order was changed, you could still
switch to an exact pair of the two.
You just have to identify them by the fpc-src sha1, instead of the
fpc-build sha1.
As I see it, from all I gathered, for just being able to identify an
exact pair/combination => either way works. The current works, of course
it does. But switched also would work (well maybe I still miss something).
The questions is/are just
- are there advantage by identifying the pair from the one or the other?
- would a monthly or bi-monthly "update" in fpc-src (and some during
release preparation) be worse or better than 3 per day on fpc-build?
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.
So fpc doc then also would need to be a submodule of fpc source.
Well, not sure nested submodule in fpc-build might work too, but has no
advantage.
Question is how many "update" commits fpc doc then triggers.
I guess docs are updated independent of the changes that triggers there
change (i.e. adding a property will not add the docs, the docs come later)?
Then the "update" of the submodule would only be needed when release
testing starts?
---------------
Of course if it really is ONLY for combining the 3 repos for release
build (including test builds of that) then you could have an empty repo,
that just has all 3 as submodules.
It would not have automated updates. Whoever want to start a release
build (from HEAD) will do one update, and can then ask others to use the
fpc-rel-group sha1 for their tests.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
