Describe the feature request
The gist of it is that I have a .cmm file in a project that should be linked into the final executable.
Pre-3.12 we used a workaround to deal with #8639 where we would add the cmm file to ghc-options and that worked as it would add Foo.cmm to the link step invocation of ghc which would then compile and linke the resulting .o file into the executable as well.
With >= Cabal 3.12 this results in linker errors as cabal hands the cmm derived .o file to the linker now as it always should have and the workaround adds it another time, resulting in duplicate symbols.
Ideally I would work around this using something like if cabal < 3.12: ghc-options: Foo.cmm but there does not seem to be a obvious way to do so.
Concretely I have:
executable run-it
main-is: Run.hs
cmm-sources: Trampoline.cmm
-- Workaround Cabal < 3.12 since Cabal doesn't link cmm-sources into executables
ghc-options: Trampoline.cmm
build-depends: base,
unix,
mmap
ghc-options: -Wall -Wno-unticked-promoted-constructors
default-language: Haskell2010
In this specific case the package is typically only built via a script so I can add a flag that corresponds to a cabal version predicate that I compute in the bash script. But having the ability to do this in the cabal file itself seems a lot cleaner and not all that far fetched.
Describe the feature request
The gist of it is that I have a .cmm file in a project that should be linked into the final executable.
Pre-3.12 we used a workaround to deal with #8639 where we would add the cmm file to
ghc-optionsand that worked as it would add Foo.cmm to the link step invocation of ghc which would then compile and linke the resulting .o file into the executable as well.With >= Cabal 3.12 this results in linker errors as cabal hands the cmm derived .o file to the linker now as it always should have and the workaround adds it another time, resulting in duplicate symbols.
Ideally I would work around this using something like
if cabal < 3.12: ghc-options: Foo.cmmbut there does not seem to be a obvious way to do so.Concretely I have:
In this specific case the package is typically only built via a script so I can add a flag that corresponds to a cabal version predicate that I compute in the bash script. But having the ability to do this in the cabal file itself seems a lot cleaner and not all that far fetched.