Description
Over the past two months I've been figuring out how to write bindings to the Vulkan API and I've ended up with the following monstrocity of a Cabal file: vulkan-raw.cabal. Roughly 350 flags for every extension, all pulling bits and pieces from a shared pool of definitions; any combination of flags enabled should be valid and leaving some modules hanging when removing extensions won't lead to an error.
Structuring the library this way means the compilation times are way lower (down to ~45 seconds on my machine from the original 5 minutes) and it can be run on a much wider set of API versions (Vulkan does not guarantee API compatibility neither forwards, nor backwards, described here).
This works fine under Cabal 3.6.2.0, but 3.8.1.0 denies it with Duplicate modules in library
, I assume this was introduced with #7966.
From the point of view of Cabal (and Hackage) design, is what I'm trying to do here actually incorrect or is this simply an insanely rare sidecase not accounted for? In the former case I need to restructure the library; in the latter the library is fine, but is incompatible with a few Cabal versions and probably Hackage.