Add argo submodule and build #853
Conversation
This commit moves the `saw-remote-api` package from the `argo` repository to the `saw-script` repository.
This reverts commit 5e598fa.
It's still part of the test suite
.github/ci.sh
Outdated
| @@ -10,7 +10,7 @@ mkdir -p "$BIN" | |||
| is_exe() { [[ -x "$1/$2$EXT" ]] || command -v "$2" > /dev/null 2>&1; } | |||
|
|
|||
| extract_exe() { | |||
| exe="$(cabal v2-exec which "$1$EXT")" | |||
| exe="$(cabal v2-exec which "$1$EXT" | tail -1)" | |||
There was a problem hiding this comment.
I'm starting to think that using find directly on the dist-newstyle folder might achieve better results. It seems to be a more common practice than cabal v2-exec from other repos I've seen as well.
There was a problem hiding this comment.
Yeah, that might be the way to go. I've had endless trouble with v2-exec. I'll update it.
There was a problem hiding this comment.
@atomb, I'm curious as to what problems you saw with v2-exec. The advantage of the v2-exec method over the find method is that the dist-newstyle can have multiple instances of the binary because it creates different directories based on architecture, GHC version, etc., so the find might not get the one for the current configuration (esp. with caching of builds).
There was a problem hiding this comment.
One some platforms, for reasons I don't entirely understand, the output of v2-exec which ... includes extra text, and it can be hard to extract what you need. Usually, tail is enough, but it seems like more of a hack. I'm hoping that in CI the issue of multiple instances of a particular binary won't show up, but maybe I'm wrong about that.
There was a problem hiding this comment.
@jared-w, is the github actions caching a potential issue for the find-based approach returning the wrong executable?
| @@ -117,12 +118,12 @@ build() { | |||
| ghc_ver="$(ghc --numeric-version)" | |||
| cp cabal.GHC-"$ghc_ver".config cabal.project.freeze | |||
| cabal v2-update | |||
| cabal v2-configure -j2 --minimize-conflict-set | |||
| echo "allow-newer: all" >> cabal.project.local | |||
There was a problem hiding this comment.
Is there a plan of sorts to eventually not need this?
There was a problem hiding this comment.
I hope so? It's really out of our control, and depends on Hackage authors not putting unnecessary upper bounds on the versions of their dependencies.
Update stack.yaml files to work with #853.
This adds the
argorepository as a submodule as a temporary step in migrating thesaw-remote-apipackage from theargorepository to thesaw-scriptrepository. More detail on this migration is here.I'd like to consider this to be as close as possible to an atomic move from the
argorepository, so I don't think it's necessary to review the purely added files, just those in the build and CI system that were changed to accommodate the new code.