flycheck-haskell breaks with library-vanilla:false and shared:true, executable-dynamic:true under cabal sandbox #23
Comments
|
@da-x I'm sorry, but your description is a little imprecise. Which imports fail? Imports of dependencies, or of modules from your package? Also, what does “fail” mean? Also, I'm not sure about the last paragraph. I might be mistaken, but as far as I know the default of Please try to be more precise. At best, give me a recipe to reproduce the issue from scratch, ideally with a vanilla |
|
Oops, sorry - I meant to write library-vanilla, and instead copy-pasted the wrong variable. Edited. I'm happy to provide you with more details. The imports that fail (ghc's "Could not find module") are dependencies of the local package, i.e. stuff that comes from the sandbox. I managed to reproduce it with yaml package. But I guess it would break on any package that has dependencies that come from the cabal sandbox.
So far so good. But then try to open Text/Libyaml.hs, followed your suggestion with Pasted 'cabal sandbox hc-pkg list' below just to see the dependencies are really there as far as the sandbox is concerned: |
da-x
changed the title
|
@da-x Well, there are no dependencies anymore. By disabling vanilla libraries, you've just opted out from building the dependencies. You only have the profiling libraries left, but GHC doesn't look for these, because Flycheck doesn't pass I'd argue that Flycheck is right here: It's a configuration issue on your side. Is there a reason why you disable vanilla libraries? As far as I know, vanilla and profiling libraries can co-exist side by side, so there's no need to disable the former in order to get the latter. You just need to enable profiling for your own package with |
|
(edited for typos/formatting) With "library-vanilla: True" and "shared:True", ghc links both the static and the dynamic binaries of the libraries, e.g: This increases the storage footprint of the cabal sandbox by a factor 2. However with I also have profiling disabled. The purpose of this configuration is to avoid linking static libraries completely, so that there are no static archive files under the cabal sandbox, and in addition, the executable under the bin directory are dynamically linked to their dependencies in the cabal sandbox which are all arriving as shared libraries. Dynamically linked binaries are much smaller. For example when building the hakyll package the result binary is a few KBs instead of 80 MB. I am not sure that flycheck is right here, as 'cabal repl' is able to find the dependencies inside the sandbox even though they are no static libraries (for the yaml package, I needed to add -fPIC to cc-options, will push this fix upstream). I think this information can be transferred to flycheck via the get-cabal-configuration.hs method.
This is how the ghci is executed via 'cabal repr'. Not sure how the information about the DSOs gets there. |
|
@da-x I wasn't aware that
Besides, for this reason Flycheck however has no chance to figure out whether your sandbox is build with or without static libraries. All it could do is to pass OTOH, all that you gain by |
|
Beside space, it also affects module build compilation time, though I don't have actual measurements. test.sh: shared-only, library-vanilla: False shared+static, library-vanilla: True Space: How about detecting ghc's version, then passing -shared if it's 7.8 and above and not pass it if otherwise? If you post a branch I'll test it. |
|
@da-x I appreciate your offer, but you'll understand that I have a hard time to see why I should write the code that saves you some 15 seconds of build time and a dozen of megabytes disk space. I find that the balance between effort and gain isn't quite right here. If that's so important to you, copy the definition of |
|
@da-x I'll add a catch-all option for arbitrary arguments to Closing as |
Consider the following under ~/.cabal/config:
With cabal sandbox for building some package (ghc 7.8.3) and the settings above, imports of the package fail during during flycheck's run.
I switched off library-vanilla back to the default of True, rebuilt the cabal sandbox and it fixed it. So I am guessing that the ghc invocation did not receive the right parameters for loading the shared library builds.
(EDITS: fixes)
The text was updated successfully, but these errors were encountered: