Open tjtolon opened 8 years ago
If you're up for it, the easiest thing may be to hack roshask to call stack exec hc-pkg
. I'm not 100% certain on that stack exec
syntax, but that's the way to use stack's tools. If the quick fix works, we can slot it into the logic that decides whether to use ghc-pkg
or hc-pkg
.
Now I tried it for a few minutes and it seems that just having cabal installed in stack's global project is not enough. At least cabal sandbox hc-pkg list ROS-std-msgs-0.3
returns with
cabal: The program 'ghc' version >=6.4 is required but it could not be found.
For me this quickly goes out of my expertise. For what I looked I'm not sure how to make a check wether a package is installed for the proper snapshot. Another ought to be added is the way how the generated cabal package is installed to the stack. I think stack.yaml should be made as well, but that could be easier with stack solver --modify-stack-yaml
or stack init --solver
For my own purposes, I will be installing roshask/cabal/ghc directly, without stack, for now.
Proper stack support is a good idea, and given the traction stack has, is rapidly becoming a necessity. Thanks for bringing this up. I'll have to set up an environment for testing this.
I've started by adding a stack.yaml
so roshask
itself builds with stack
. It also looks like stack exec ghc-pkg
can get us installed package information. The last step @tjtolon mentioned of producing a stack.yaml
for each package is still to-be-determined.
I made a new ros package with
roshask create test std_msgs
where roshask was installed via stack. However, executingroshask dep
on the created package returns withI looked a bit into the code and noticed that roshask checks if the dependent have been build using ghc-pkg, or if something is cabal sandboxed, hc-pkg. Now, if I'm not completely wrong, there is no such thing as ghc-pkg for stack as it utilizes its own package database.
Is it true that for now the best option would be to install ghc and cabal on the system directly?