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:
Anyway, if we reverse the order, then if I understand everything
correctly we would have the robo commits to advance the fpcbuild
submodule link in the fpc/ repo ? No thanks!
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, ....
- 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
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.
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?
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?
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
