On 2021-09-06 11:48, Ben Cooksley wrote:
On Mon, Sep 6, 2021 at 9:00 PM Tom Zander <t...@flowee.org> wrote:
On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote:
In terms of the format of the 'Dependencies' section,
Playing with kde-build script and noticing the fast growing
dependency trees we have today, I think it may be beneficial to
have two types of compile dependencies in this setup.
1. required-to-build.
Which means that if something in the parent tree changes, this
one is scheduled for re-build.
2. optional. Equivalent of the cmake feature, if its not there
some code is not compiled.
At least once before a release the full dependencies can be
compiled to see if it fully compiles.
From the perspective of the CI system there is basically no difference
in terms of making a dependency available or not as all dependencies
are always satisfied using previously built binaries.
If a dependency is not available your build fails.
We also have to make a hard choice - we either bring in optional
dependencies or we don't.
If we were to randomise whether we brought them in - or just brought
them in at certain times - then we would make the system state
deterministic. This could in some cases cause builds to break if it
was random whether or not we included optional dependencies. This
would occur if the dependency of a dependency of a project were
rebuilt without an optional dependency being present which in turn
caused it's API interface to change. That would then cause the project
to fail as the dependency would now be broken.
Pushing everything into required is likely not scalable, causing
projects too wait too long for compile.
Avoiding the optional ones means you lack coverage of compile and
testing failures due to changes in libs.
The CI system has reused the results of previous builds of
dependencies since the very first generation of the system (this would
be generation 5) so this is not a problem facing the CI system.
For individual developers, my understanding is that kdesrc-build makes
use of incremental builds which eliminates most of the issue as well.
What do people think, is it useful to have an 'optional' category
in future there?
Maybe useful to think that far ahead now people are populating
their dependencies :-)
Hi,
I would prefer to not have some optional category to be sure
the CI always builds with the same state of dependencies, too.
Greetings
Christoph
--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org
