Possible race condition between `--include-easyblocks` and `--include-easyblocks-from-pr`

[Crivella]

This was observed when attempting to build

https://github.com/bedroge/eb-rocm/blob/main/6.4.0/ROCm-LLVM-6.4.0-GCCcore-13.3.0.eb

on top of EESSI using the fix provided in

easybuilders/easybuild-easyblocks#3781

eb --robot ROCm-LLVM-6.4.0-GCCcore-13.3.0.eb --include-easyblocks rocm_llvm.py --include-easyblocks-from-pr 3781

From the reported behavior the fixes to EB_LLVM in the PR where not being used by the EB_ROCm_minus_LLVM child easyblock

My assumption is that --include-easyblocks is performed before --include-easyblocks-from-pr which leads to the inner EB_LLVM from easybuild being used as the actual child class of EB_ROCm_minus_LLVM instead of the one coming from the PR

Will need more investigation, and possibly rise a warning when the 2 options are combined together

[Micket]

easybuilders/easybuild-easyconfigs#23256 (comment)

Order matters indeed. Even if it's two seperate PRs, --include-easyblocks-from-pr A,B or not the same as --include-easyblocks-from-pr B,A

Edit: in case it wasn't clear, i agree this is a bug and it shouldn't happen. It should be independent of order when there isn't any overlap of easyblocks.