SUMMARY

Ideally, building the project twice on equivalent systems should result in the same bit-by-bit result. This helps verify there's been no compromise of build systems, especially when the project is part of a larger aggregate. You can read more about this at https://reproducible-builds.org/.

libplasma seems quite close to being reproducible, but to suffer from an issue similar to https://qt-project.atlassian.net/browse/QTBUG-137440: a missing explicit library dependency in the CMakeLists.txt of a project using qml leads to a nondeterminism in what code is generated for it.

This issue was identified while reproducing the NixOS graphical installation issue, and is tracked there as https://github.com/NixOS/nixpkgs/issues/458839

STEPS TO REPRODUCE

Build libplasma in an 'essentially equivalent' environment, but for example varying the parallelism between '2' and '16'. 

OBSERVED RESULT

Different generated code / output.

Specifically,  the generated build/src/declarativeimports/plasmaextracomponents/.rcc/qmlcache/plasmaextracomponentsplugin_qml/BasicPlasmoidHeading_qml.cpp from ./src/declarativeimports/plasmaextracomponents/qml/BasicPlasmoidHeading.qml is different. For 6.5.3, the methods not consistently generated are for `visible at line 127, column 13` and `text at line 128, column 13`.

Both of those refer to PlasmaCore.Action, so perhaps that's the missing link. QML_NAMED_ELEMENT(Action) is found in src/declarativeimports/core/corebindingsplugin.h, so maybe src/declarativeimports/plasmaextracomponents/CMakeLists.txt needs to explicitly depend on the corebindingsplugin.

I'm not familiar enough with QML to go from here to actually specifying that dependency, though - I'd be happy to test further if you can point me in the right direction!

EXPECTED RESULT

The same generated code / output