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
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
