We are talking about build matrix, linters, debug on CI etc. My preference would be have a dedicated repo for infrastructure and be able to use as dependency in each repo (e.g., optional26 to have as a submodule this infrastructure repo; I’m open to any dependency like support - need to test this idea).
Advantages:
no duplication for infrastracture
fast way to deliver updates
we can have a stable branch/version which is pulled by other repos and keep main as a development branch.
We didn’t have time to discuss this at the sync. Open earlier discussion here.
I would say yes, for the reasons you listed. It will greatly reduce duplication and also make it easier for existing Beman projects that are missing some aspects of infrastructure to integrate it.
Making it easier to support library layout expectations on different environments
Making GitHub Actions less repetitive by having common build-run-and-test scripts, etc.
I have had in mind adding dependencies to account for the above also. But I have been hesitant to do so before we get some reasonable support for Conan and vcpkg.
It would be possible to use FetchContent for this, I believe. Perhaps that is the best option for now. But we should be willing to prioritize support of packaging, even if we have to rethink our use of git-submodules, for instance.
The downside of having it outside the project is that projects get broken by changes outside their span of control. With a distributed project we can’t even do a forkift upgrade of everything in github, because that still means peoples working branches are broken.
If the infrastructure is shared, it also tends to be frozen because of the perceived costs of change.
I think this idea is worthy of further investigation, but it’s hard to know if it would be better without knowing exactly how it is implemented. Submodules confuse people, it’s unclear how FetchContent would work with pre-commit, .clang-format wants to live in the top-level directory, incremental dependency upgrade paths, etc.
@neatudarius do you have a concrete idea for how a separate infrastructure repo would work? Without that I’m afraid it’s tough to give feedback.
Currently we have different degree of infrastructure tool implementation across beman, can we sync up/ propagate between projects these improvements to minimize duplicate code?
I will go first:
Exemplar have:
Lint infrastructure + review dog
Preset of GCC variants
Single platform CI testing across major C++ version and sanitizers
Enable/ disable examples build
Enable/ disable testing
Devcontainer/ codespace support
Exemplar will benefit from:
Clang-tidy support (currently in the works, will help from reference implementation)
Multi-platform CI testing (windows in the works, macos pending PR by @ClausKlein )
[CMAKE.CONFIG] (in progress/ stale PR by @neatudarius , I think this is implemented elsewhere)
Code coverage infrastructure
Doxygen (I think this is implemented elsewhere)
VCPKG support (need expertise, especially CI side)
Compiler version testing matrix on CI (I think this is implemented elsewhere)
Let me know if the project you are working will benefit anything from exemplar (I will shoot a PR over), and you have implemented any other tools exemplar doesn’t currently have.
@neatudarius
Would you mind deleting this thread and move your exact message in Should we have a dedicated repo for infrastructure?? (Or at least delete it temporarily). Or at least defer any work to copy infrastructure until we finish the other thread.
I think we need to have a reusable infrastructure, then your call to action would be possible in a scalable way.