Hadrian: work around Cabal's/GHC's different Arch/OS strings
ClosedPublic

Authored by harpocrates on Nov 20 2018, 12:36 PM.

Details

Summary

The path to the 'include' subdirectory of 'rts' includes a folder that
whose name is generated by Cabal and mentiones the architecture and OS.
For example:

_build/stage1/lib/x86_64-osx-ghc-8.7.20181120/rts-1.0/include

Hadrian needs to be aware that Cabal renders architectures and OSes in
a slightly different way than GHC. There is already symmetric logic in
Cabal (for working with GHC environment files, which follow GHC's naming
conventions).

Test Plan

./hadrian/build.sh -c "binary-dist" # on mac

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
harpocrates created this revision.Nov 20 2018, 12:36 PM
snowleopard accepted this revision.Nov 20 2018, 3:08 PM

Thank you! This looks good to me, although we should remember to merge this commit with Hadrian: prefix, since it's a Hadrian-only commit.

I wonder if adding the inverse functions to Cabal would be a better solution in the long term, so that both directions could be maintained in one place. Perhaps, @bgamari @alpmestan could share their thoughts?

This revision is now accepted and ready to land.Nov 20 2018, 3:08 PM
harpocrates retitled this revision from Work around Cabal's/GHC's different Arch/OS strings in Hadrian to Hadrian: work around Cabal's/GHC's different Arch/OS strings in Hadrian.Nov 20 2018, 3:13 PM
harpocrates retitled this revision from Hadrian: work around Cabal's/GHC's different Arch/OS strings in Hadrian to Hadrian: work around Cabal's/GHC's different Arch/OS strings.
This revision was automatically updated to reflect the committed changes.
alpmestan added a comment.EditedNov 22 2018, 2:13 PM

It would certainly be ideal to eventually have the inverse functions live in the same place, to avoid "silent breakage" when definitions are changed in one place but not the other.