external/BepInEx.ConfigurationManager-master is the upstream source this fork references, but it's gitignored, isn't a git submodule, and no README or build step documents how to populate it. So a fresh clone can't build the upstream reference — the folder simply isn't there, and nothing tells a contributor how to get it. It only works on a machine where someone fetched it by hand at some point.
Make it reproducible so a clean clone builds without tribal knowledge. Either option closes this:
- Add
external/BepInEx.ConfigurationManager-master as a git submodule pinned to the upstream commit.
- Add a documented fetch step — a script or a build target — that populates
external/ on demand, and reference it in the README.
Surfaced while building the ConfigurationManager e2e suite: because a fresh clone couldn't build the upstream plugin here, that suite vendors a prebuilt ConfigurationManager.dll instead. That sidesteps the problem for the e2e repo, but the gap still blocks this repo's own contributors.
external/BepInEx.ConfigurationManager-masteris the upstream source this fork references, but it's gitignored, isn't a git submodule, and no README or build step documents how to populate it. So a fresh clone can't build the upstream reference — the folder simply isn't there, and nothing tells a contributor how to get it. It only works on a machine where someone fetched it by hand at some point.Make it reproducible so a clean clone builds without tribal knowledge. Either option closes this:
external/BepInEx.ConfigurationManager-masteras a git submodule pinned to the upstream commit.external/on demand, and reference it in the README.Surfaced while building the ConfigurationManager e2e suite: because a fresh clone couldn't build the upstream plugin here, that suite vendors a prebuilt
ConfigurationManager.dllinstead. That sidesteps the problem for the e2e repo, but the gap still blocks this repo's own contributors.