cabal: Add necessary aliases for vendored packages with executables #2309
Conversation
There was a problem hiding this comment.
Thank you!
It took me a while to figure out what's going on; so for posterity and to remind myself:
For stack_snapshot there will be a repository called stackage (let's say) and for each of the library components there will be a haskell_cabal_library target.
For exe components, there will be a haskell_cabal_binary target (called _<name>_exe_<exe-name>). But also, there will be an alias (just exe-name) in the stackage-exe repository pointing to the actual haskell_cabal_binary in stackage.
For vendored packages, the haskell_binary_target does not exist in stackage, so this needs another alias pointing to the actual exe target in the repository of the vendored package.
|
@iteratee somehow CI failed and I cannot seem to retry it. Could you please rebase and re-push your branch? |
iteratee
force-pushed
the
kb/vendored-cabal-exe
branch
2 times, most recently
from
7537a28 to
24387ed
Compare
This allows vendoring of packages with necessary tools from a stack snapshot. For example, if the cabal file for `cpphs` hasn't yet been bumped on hackage with increased bounds for the newest ghc.
iteratee
force-pushed
the
kb/vendored-cabal-exe
branch
from
24387ed to
23e24da
Compare
I rebased and CI is more happy, but the windows tests failed. I can rebase again, but it would help to know if that was transient, expected, soon to be fixed, etc. |
Thank you! This seems to be the same error we also saw in #2312. It only seems to happen for PRs having no access to the Buildbuddy API secret. So, that seems to be a caching issue and not related to this change. |
This allows vendoring of packages with necessary tools from a stack snapshot. For example, if the cabal file for
cpphshasn't yet been bumped on hackage with increased bounds for the newest ghc.