New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support all architectures and OSs that GHC and Cabal support #344
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make sure that travis-ci passes.
src/Cabal2nix.hs
Outdated
-- | Replicate the normalization performed by GHC_CONVERT_CPU in GHC's aclocal.m4 | ||
-- since the output of that is what Cabal parses. | ||
ghcConvertArch :: String -> String | ||
ghcConvertArch = \case |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the use of LambdaCase here really necessary? It feels like this code could easily have been written with normal pattern matching and it would look almost exactly the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally prefer to not duplicate identifiers unnecessarily - especially with pattern guards that apply to the thing being cased on: case foo of { foo' | foo' == bar -> ... }
or case foo of { _ | foo == bar -> ... }
?
Happy to change the style if you want it the other way though. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer the conventional style, yes. I believe that it can be written quite straight-forwardly without duplicating any identifiers (although I haven't actually tried it so I might be wrong).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done with use of an underscore.
src/Cabal2nix.hs
Outdated
"i586" -> "i386" | ||
"i686" -> "i386" | ||
"amd64" -> "x86_64" | ||
arch -> fromMaybe arch $ listToMaybe $ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hlint complains that the second $ is superfluous.
src/Cabal2nix.hs
Outdated
"tvos" -> "ios" | ||
"linux-android" -> "linux-android" | ||
os | "linux-" `isPrefixOf` os -> "linux" | ||
os -> fromMaybe os $ listToMaybe $ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dito
This replicates GHC's normalization logic so that Cabal's built in parsers can be used. This should ensure maximum compatibility with how the Cabal file will actually be evaluated during the build. Additionally, this adds support for passing in the full LLVM style platform triple/quadruple (e.g. x86_64-unknown-linux-gnu) instead of just the short Nix style (x86_64-linux). This will make it possible for the ABI to treated as part of the OS where applicable (e.g. linux-android). We can then change `make-package-set.nix` to use `hostPlatform.config` instead of `hostPlatform.system` to get the full information.
This replicates GHC's normalization logic so that Cabal's built in parsers can
be used. This should ensure maximum compatibility with how the Cabal file will
actually be evaluated during the build.
Additionally, this adds support for passing in the full LLVM style platform
triple/quadruple (e.g. x86_64-unknown-linux-gnu) instead of just the short Nix
style (x86_64-linux). This will make it possible for the ABI to treated as part
of the OS where applicable (e.g. linux-android). We can then change
make-package-set.nix
to usehostPlatform.config
instead ofhostPlatform.system
to get the full information.