Skip to content

Elaboration on duplicate module support #8771

Closed
@BurningWitness

Description

@BurningWitness

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions