Closed mouse07410 closed 5 years ago
rikvdkleij
commented
5 years ago It's not what you think it is...
That message is from that the plugin is using Stack to install the Haskell tools like hlint in an IntelliJ sandbox. Has nothing to do with your project. That LTS version is fixed to prevent API compatibility issues with Haskell tools.
Your issue is: https://github.com/commercialhaskell/stack/issues/825
mouse07410
commented
5 years ago It's not what you think it is...
Unfortunately, yes it is. Believe me, I've researched this issue when it hit me way before I started my attempts to use your plugin. And the solution I had to pick (because I cannot allow /usr/lib to precede /opt/local/lib on the search path, and because attempts to put the Apple-provided libiconv.dylib that libHSbase.a from GHC in the Haskell Platform expects into a special directory and put that directory first on the library search path did not work) was to make GHC that doesn't mind Macports. And everything worked - until your plugin started to enforce its view on what compiler/etc. should be used by forcing LTS.
That message is from that the plugin is using Stack to install the Haskell tools like hlint in an IntelliJ sandbox
Yes, and the problem is with the way your plugin is doing it.
That LTS version is fixed to prevent API compatibility issues with Haskell tools
Please give the user the possibility to "unfix" it. For example, my LTS is 13.2, and I'm forcing my compiler (and things that I need to work - work fine with it):
resolver: lts-13.2
system-ghc: true
skip-ghc-check: trueYour issue is: https://github.com/commercialhaskell/stack/issues/825
Yes, that's the root cause - the question is how to work around it. Your plugin prevents the workaround - unnecessarily, I think.
I am asking again - since your plugin, as you said in your README, depends mainly on Stack and Intero, and I have both of these working fine - please add the feature to use intero, hlint, hoogle, etc. that are already installed. For example:
$ type hlint
hlint is /Users/uri/Library/Haskell/bin/hlint
$ hlint --version
HLint v2.1.12, (C) Neil Mitchell 2006-2018
$ type intero
intero is /Users/uri/Library/Haskell/bin/intero
$ intero --version
Intero 0.1.35
$ type hindent
hindent is /Users/uri/.local/bin/hindent
$ hindent --version
hindent 5.2.7
$ type stack
stack is /usr/local/bin/stack
$ stack --version
Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
$ type stylish-haskell
stylish-haskell is /Users/uri/.local/bin/stylish-haskell
$ stylish-haskell --version
stylish-haskell 0.9.2.0
$ To demonstrate that everything (else) is working on my setup:
$ cabal install hoogle
Warning: The install command is a part of the legacy v1 style of cabal usage.
Please switch to using either the new project style and the new-install
command or the legacy v1-install alias as new-style projects will become the
default in the next version of cabal-install. Please file a bug if you cannot
replicate a working v1- use case with the new-style commands.
For more information, see: https://wiki.haskell.org/Cabal/NewBuild
Resolving dependencies...
Downloading appar-0.1.7
Downloading auto-update-0.1.4
Downloaded auto-update-0.1.4
Downloading basement-0.0.8
Starting auto-update-0.1.4
Downloaded basement-0.0.8
Downloading blaze-builder-0.4.1.0
Downloaded appar-0.1.7
Starting appar-0.1.7
Starting basement-0.0.8
Downloaded blaze-builder-0.4.1.0
Starting blaze-builder-0.4.1.0
Building auto-update-0.1.4
Building basement-0.0.8
Building appar-0.1.7
Building blaze-builder-0.4.1.0
Completed auto-update-0.1.4
Downloading bsb-http-chunked-0.0.0.4
Downloaded bsb-http-chunked-0.0.0.4
Starting bsb-http-chunked-0.0.0.4
Completed appar-0.1.7
Downloading byteable-0.1.1
Downloaded byteable-0.1.1
Starting byteable-0.1.1
Building bsb-http-chunked-0.0.0.4
Building byteable-0.1.1
Completed byteable-0.1.1
Downloading byteorder-1.0.4
Downloaded byteorder-1.0.4
Starting byteorder-1.0.4
Completed bsb-http-chunked-0.0.0.4
Downloading case-insensitive-1.2.0.11
Downloaded case-insensitive-1.2.0.11
Starting case-insensitive-1.2.0.11
Building byteorder-1.0.4
Building case-insensitive-1.2.0.11
Completed blaze-builder-0.4.1.0
Downloading cereal-0.5.7.0
Downloaded cereal-0.5.7.0
Starting cereal-0.5.7.0
Building cereal-0.5.7.0
Completed byteorder-1.0.4
Downloading cookie-0.4.4
Downloaded cookie-0.4.4
Starting cookie-0.4.4
Building cookie-0.4.4
Completed case-insensitive-1.2.0.11
Downloading easy-file-0.2.2
Downloaded easy-file-0.2.2
Starting easy-file-0.2.2
Building easy-file-0.2.2
Completed cookie-0.4.4
Downloading fmlist-0.9.2
Downloaded fmlist-0.9.2
Starting fmlist-0.9.2
Building fmlist-0.9.2
Completed easy-file-0.2.2
Downloading generic-deriving-1.12.2
Downloaded generic-deriving-1.12.2
Starting generic-deriving-1.12.2
Building generic-deriving-1.12.2
Completed fmlist-0.9.2
Downloading hourglass-0.2.12
Downloaded hourglass-0.2.12
Starting hourglass-0.2.12
Building hourglass-0.2.12
Completed cereal-0.5.7.0
Downloading http-date-0.0.8
Downloaded http-date-0.0.8
Starting http-date-0.0.8
Building http-date-0.0.8
Completed hourglass-0.2.12
Downloading js-flot-0.8.3
Downloaded js-flot-0.8.3
Starting js-flot-0.8.3
Completed http-date-0.0.8
Downloading js-jquery-3.3.1
Downloaded js-jquery-3.3.1
Starting js-jquery-3.3.1
Building js-flot-0.8.3
Building js-jquery-3.3.1
Completed js-jquery-3.3.1
Downloading mime-types-0.1.0.9
Downloaded mime-types-0.1.0.9
Starting mime-types-0.1.0.9
Completed js-flot-0.8.3
Downloading mmap-0.5.9
Downloaded mmap-0.5.9
Starting mmap-0.5.9
Building mime-types-0.1.0.9
Building mmap-0.5.9
Completed mmap-0.5.9
Downloading network-byte-order-0.0.0.0
Downloaded network-byte-order-0.0.0.0
Starting network-byte-order-0.0.0.0
Building network-byte-order-0.0.0.0
Completed network-byte-order-0.0.0.0
Downloading network-uri-2.6.1.0
Downloaded network-uri-2.6.1.0
Starting network-uri-2.6.1.0
Building network-uri-2.6.1.0
Completed mime-types-0.1.0.9
Downloading psqueues-0.2.7.0
Downloaded psqueues-0.2.7.0
Starting psqueues-0.2.7.0
Building psqueues-0.2.7.0
Completed generic-deriving-1.12.2
Downloading simple-sendfile-0.2.27
Downloaded simple-sendfile-0.2.27
Starting simple-sendfile-0.2.27
Building simple-sendfile-0.2.27
Completed network-uri-2.6.1.0
Downloading tar-0.5.1.0
Downloaded tar-0.5.1.0
Starting tar-0.5.1.0
Building tar-0.5.1.0
Completed simple-sendfile-0.2.27
Downloading typed-process-0.2.3.0
Downloaded typed-process-0.2.3.0
Starting typed-process-0.2.3.0
Building typed-process-0.2.3.0
Completed typed-process-0.2.3.0
Downloading unix-compat-0.5.1
Downloaded unix-compat-0.5.1
Starting unix-compat-0.5.1
Completed psqueues-0.2.7.0
Downloading unix-time-0.4.4
Downloaded unix-time-0.4.4
Starting unix-time-0.4.4
Building unix-compat-0.5.1
Completed basement-0.0.8
Downloading utf8-string-1.0.1.1
Downloaded utf8-string-1.0.1.1
Starting utf8-string-1.0.1.1
Completed unix-compat-0.5.1
Downloading utility-ht-0.0.14
Building utf8-string-1.0.1.1
Downloaded utility-ht-0.0.14
Starting utility-ht-0.0.14
Building utility-ht-0.0.14
Building unix-time-0.4.4
Completed tar-0.5.1.0
Downloading vault-0.3.1.2
Downloaded vault-0.3.1.2
Starting vault-0.3.1.2
Building vault-0.3.1.2
Completed unix-time-0.4.4
Downloading word8-0.1.3
Downloaded word8-0.1.3
Starting word8-0.1.3
Completed utf8-string-1.0.1.1
Downloading zlib-0.6.2
Downloaded zlib-0.6.2
Starting zlib-0.6.2
Building word8-0.1.3
Completed vault-0.3.1.2
Downloading iproute-1.7.7
Downloaded iproute-1.7.7
Starting iproute-1.7.7
Building zlib-0.6.2
Building iproute-1.7.7
Completed word8-0.1.3
Downloading http-types-0.12.2
Downloaded http-types-0.12.2
Starting http-types-0.12.2
Building http-types-0.12.2
Completed utility-ht-0.0.14
Downloading socks-0.5.6
Downloaded socks-0.5.6
Starting socks-0.5.6
Building socks-0.5.6
Completed zlib-0.6.2
Downloading http2-1.6.4
Completed http-types-0.12.2
Downloading memory-0.14.18
Downloaded memory-0.14.18
Starting memory-0.14.18
Downloaded http2-1.6.4
Building memory-0.14.18
Completed iproute-1.7.7
Downloading foundation-0.0.21
Downloaded foundation-0.0.21
Starting http2-1.6.4
Starting foundation-0.0.21
Building foundation-0.0.21
Building http2-1.6.4
Completed socks-0.5.6
Downloading fast-logger-2.4.13
Downloaded fast-logger-2.4.13
Starting fast-logger-2.4.13
Building fast-logger-2.4.13
Completed fast-logger-2.4.13
Downloading ListLike-4.6
Downloaded ListLike-4.6
Starting ListLike-4.6
Building ListLike-4.6
Completed memory-0.14.18
Downloading storable-record-0.0.4
Downloaded storable-record-0.0.4
Starting storable-record-0.0.4
Building storable-record-0.0.4
Completed storable-record-0.0.4
Downloading streaming-commons-0.2.1.0
Downloaded streaming-commons-0.2.1.0
Starting streaming-commons-0.2.1.0
Building streaming-commons-0.2.1.0
Completed http2-1.6.4
Downloading wai-3.2.1.2
Downloaded wai-3.2.1.2
Starting wai-3.2.1.2
Building wai-3.2.1.2
Completed wai-3.2.1.2
Downloading pem-0.2.4
Downloaded pem-0.2.4
Starting pem-0.2.4
Building pem-0.2.4
Completed pem-0.2.4
Downloading cryptonite-0.25
Downloaded cryptonite-0.25
Starting cryptonite-0.25
Building cryptonite-0.25
Completed streaming-commons-0.2.1.0
Downloading asn1-types-0.3.2
Downloaded asn1-types-0.3.2
Starting asn1-types-0.3.2
Building asn1-types-0.3.2
Completed asn1-types-0.3.2
Downloading storable-tuple-0.0.3.3
Downloaded storable-tuple-0.0.3.3
Starting storable-tuple-0.0.3.3
Building storable-tuple-0.0.3.3
Completed storable-tuple-0.0.3.3
Downloading wai-logger-2.3.4
Downloaded wai-logger-2.3.4
Starting wai-logger-2.3.4
Building wai-logger-2.3.4
Completed wai-logger-2.3.4
Downloading warp-3.2.25
Downloaded warp-3.2.25
Starting warp-3.2.25
Building warp-3.2.25
Completed foundation-0.0.21
Downloading http-client-0.5.14
Downloaded http-client-0.5.14
Starting http-client-0.5.14
Building http-client-0.5.14
Completed ListLike-4.6
Downloading conduit-extra-1.3.0
Downloaded conduit-extra-1.3.0
Starting conduit-extra-1.3.0
Building conduit-extra-1.3.0
Completed warp-3.2.25
Downloading asn1-encoding-0.9.5
Downloaded asn1-encoding-0.9.5
Starting asn1-encoding-0.9.5
Building asn1-encoding-0.9.5
Completed conduit-extra-1.3.0
Downloading process-extras-0.7.4
Downloaded process-extras-0.7.4
Starting process-extras-0.7.4
Building process-extras-0.7.4
Completed asn1-encoding-0.9.5
Downloading asn1-parse-0.9.4
Downloaded asn1-parse-0.9.4
Starting asn1-parse-0.9.4
Completed http-client-0.5.14
Building asn1-parse-0.9.4
Completed asn1-parse-0.9.4
Completed process-extras-0.7.4
Completed cryptonite-0.25
Downloading x509-1.7.5
Downloaded x509-1.7.5
Starting x509-1.7.5
Building x509-1.7.5
Completed x509-1.7.5
Downloading x509-store-1.6.7
Downloaded x509-store-1.6.7
Starting x509-store-1.6.7
Building x509-store-1.6.7
Completed x509-store-1.6.7
Downloading x509-validation-1.6.11
Downloading x509-system-1.6.6
Downloaded x509-system-1.6.6
Starting x509-system-1.6.6
Downloaded x509-validation-1.6.11
Starting x509-validation-1.6.11
Building x509-system-1.6.6
Building x509-validation-1.6.11
Completed x509-system-1.6.6
Completed x509-validation-1.6.11
Downloading tls-1.4.1
Downloaded tls-1.4.1
Starting tls-1.4.1
Building tls-1.4.1
Completed tls-1.4.1
Downloading tls-session-manager-0.0.0.2
Downloading connection-0.2.8
Downloaded tls-session-manager-0.0.0.2
Starting tls-session-manager-0.0.0.2
Downloaded connection-0.2.8
Starting connection-0.2.8
Building tls-session-manager-0.0.0.2
Building connection-0.2.8
Completed tls-session-manager-0.0.0.2
Downloading warp-tls-3.2.4.3
Downloaded warp-tls-3.2.4.3
Starting warp-tls-3.2.4.3
Building warp-tls-3.2.4.3
Completed connection-0.2.8
Downloading http-client-tls-0.3.5.3
Downloaded http-client-tls-0.3.5.3
Starting http-client-tls-0.3.5.3
Building http-client-tls-0.3.5.3
Completed warp-tls-3.2.4.3
Completed http-client-tls-0.3.5.3
Downloading http-conduit-2.3.4
Downloaded http-conduit-2.3.4
Starting http-conduit-2.3.4
Building http-conduit-2.3.4
Completed http-conduit-2.3.4
Downloading hoogle-5.0.17.4
Downloaded hoogle-5.0.17.4
Starting hoogle-5.0.17.4
Building hoogle-5.0.17.4
Completed hoogle-5.0.17.4
Updating documentation index
/Users/uri/Library/Haskell/share/doc/x86_64-osx-ghc-8.6.3/index.html
Loaded package environment from /Users/uri/.ghc/x86_64-darwin-8.6.3/environments/defaultAlso, please consider allowing user to pass ghc-options: to stack. That could be another workaround, as I described in the Macports ticket I referred to.
rikvdkleij
commented
5 years ago Please give the user the possibility to "unfix" it. For example, my LTS is 13.2, and I'm forcing my compiler (and things that I need to work - work fine with it):
That is in conflict with my solution, see the discussion under this commit for more context: https://github.com/ndmitchell/hlint/commit/7bb10df6871759704a287fedea623f5142ad2154
The ~/.stack/stack.yaml is a global settings file. You can use this file to (hopefully) resolve the iconv issue.
I am asking again - since your plugin, as you said in your README, depends mainly on Stack and Intero, and I have both of these working fine - please add the feature to use intero, hlint, hoogle, etc. that are already installed
The README is still for the latest beta I have published to the stable channel of the Jetbrains plugin repo. And here I can write a whole story............
To demonstrate that everything (else) is working on my setup:
Cabal /= Stack.
rikvdkleij
commented
5 years ago Also, please consider allowing user to pass ghc-options: to stack. That could be another workaround, as I described in the Macports ticket I referred to.
Ok, will do that.
mouse07410
commented
5 years ago Cabal
/=Stack.
Yeah, but that doesn't invalidate my point - that my setup was sound and solid. Here's the "pure" stack:
$ stack install hlint
data-default-class-0.1.2.0: download
cmdargs-0.10.20: download
clock-0.7.2: download
hscolour-1.24.4: download
data-default-class-0.1.2.0: configure
data-default-class-0.1.2.0: build
clock-0.7.2: configure
data-default-class-0.1.2.0: copy/register
clock-0.7.2: build
hscolour-1.24.4: configure
data-default-instances-containers-0.0.1: download hscolour-1.24.4: build cmdargs-0.10.20: configure cmdargs-0.10.20: build data-default-instances-containers-0.0.1: configure clock-0.7.2: copy/register data-default-instances-dlist-0.0.1: download data-default-instances-containers-0.0.1: build data-default-instances-dlist-0.0.1: configure data-default-instances-containers-0.0.1: copy/register data-default-instances-dlist-0.0.1: build extra-1.6.14: download extra-1.6.14: configure 4
data-default-instances-dlist-0.0.1: copy/register
old-locale-1.0.0.7: download
extra-1.6.14: build
old-locale-1.0.0.7: configure
old-locale-1.0.0.7: build
old-locale-1.0.0.7: copy/register
data-default-instances-old-locale-0.0.1: download data-default-instances-old-locale-0.0.1: configure data-default-instances-old-locale-0.0.1: build data-default-instances-old-locale-0.0.1: copy/register extra-1.6.14: copy/register data-default-0.7.1.1: download
data-default-0.7.1.1: configure
old-time-1.1.0.3: download
data-default-0.7.1.1: build
old-time-1.1.0.3: configure
data-default-0.7.1.1: copy/register
polyparse-1.12.1: download
hscolour-1.24.4: copy/register
refact-0.3.0.2: download
cmdargs-0.10.20: copy/register
uniplate-1.6.12: download
old-time-1.1.0.3: build
polyparse-1.12.1: configure
polyparse-1.12.1: build
refact-0.3.0.2: configure
refact-0.3.0.2: build
uniplate-1.6.12: configure
uniplate-1.6.12: build
old-time-1.1.0.3: copy/register
refact-0.3.0.2: copy/register
uniplate-1.6.12: copy/register
haskell-src-exts-util-0.2.4: download
haskell-src-exts-util-0.2.4: configure
polyparse-1.12.1: copy/register
haskell-src-exts-util-0.2.4: build
cpphs-1.20.8: download
cpphs-1.20.8: configure
cpphs-1.20.8: build
haskell-src-exts-util-0.2.4: copy/register
cpphs-1.20.8: copy/register
hlint-2.1.11: download
hlint-2.1.11: configure
hlint-2.1.11: build
hlint-2.1.11: copy/register
Completed 17 action(s).
Copying from /Users/uri/.stack/snapshots/x86_64-osx/lts-13.0/8.6.3/bin/hlint to /Users/uri/.local/bin/hlint
Copied executables to /Users/uri/.local/bin:
- hlint
$ stack --version
Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
$ type hlint
hlint is /Users/uri/.local/bin/hlint
$ hlint --version
HLint v2.1.11, (C) Neil Mitchell 2006-2018
$ As you can see, works perfectly fine.
For example, my LTS is 13.2, and I'm forcing my compiler (and things that I need to work - work fine with it):
That is in conflict with my solution, see the discussion under this commit for more context...
Thank you for providing the context - very informative. I understand your position better now. I still would like to ask for an option to use system-installed components, if at all possible. Say, make your current approach a default, but offer the possibility to specify the tools explicitly?
The
~/.stack/stack.yamlis a global settings file. You can use this file to (hopefully) resolve the iconv issue.
It did not seem to work before. I will keep experimenting, but I don't have much hope here. :-(
Also, please consider allowing user to pass
ghc-options:to stack. That could be another workaround, as I described in the Macports ticket I referred to.Ok, will do that.
Yes please! This workaround worked for me with GHC itself, and with cabal. Maybe it would work with stack too, in which case a lot of things will be simplified.
rikvdkleij
commented
5 years ago I would like to know what I can change to the stack command which installs the Haskell tools to get it working for you (and in general). The stack install command is ran from the home directory.
Stack is used for:
Do they all need that extra ghc-options? Or only for installing Haskell tools and what is that ghc-option?
As a workaround you can put the tool binaries in:
~/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/bin
mouse07410
commented
5 years ago I would like to know what I can change to the stack command which installs the Haskell tools to get it working for you (and in general).
First, please know that I really appreciate your willingness to seek solution to the problem I'm experiencing.
Based on my observation, this problem is shared by everybody who uses Macports and has to put Macports libraries first in the search path (for whatever reason).
... Do they all need that extra ghc-options? ...
The problem is that libHSbase.a requires Apple-provided libiconv.dylib. It means that Macports users would need this extra option for anything Haskell-related that links with libHSbase.a -> libiconv.dylib. Therefore, I think the answer to your question is:
libHSbase.a. Some of my projects did not need that library, but I suspect that in general it is linked against more often than not.libHSbase.a, and so require Apple's libiconv.dylib.As a workaround you can put the tool binaries in:
~/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/bin
But if I do, won't the plugin try to re-build them?
Another aspect of this problem is - what LTS (and therefore what tools, and particularly, what GHC) would projects created with this plugin use? Any GHC (from any LTS or otherwise) except for the one that's been rebuilt under Macports (like what I did) would require this option. But maybe it's addressed by your first bullet point.
rikvdkleij
commented
5 years ago I have read your comments a couple of times but it's all getting too confusing for me... First some remarks.
I will not ask why not use brew :-) AFAIK most of mac developers use brew, including me. (I also use Ubuntu, btw)
But if I do, won't the plugin try to re-build them?
No, if the binary is there, no rebuild for that binary. Binaries are hlint, hoogle, hindent and stylish-haskell.
Provide a a way to affect the global .cabal template for a new project, or at least the package.yaml that's created from it.
package.yaml is leading. Stack will generate cabal file from package.yaml. Maybe this is the cause of your issue when you used your test project with IntelliJ. Btw, to import project in IntelliJ you have to select New project from existing sources and then select as External model, Haskell stack.
I had this in my stack.yaml in the project directory:
In the following Update section you also mean the project local stack config file. That's confusing.
To the best of your knowledge, which of the following directories can I delete
I do not understand why you want to delete files. Stack creates in home dir only .stack. I only delete that whole directory when stack behaves weird, so something had worked and suddenly not anymore.
And it is trying to rebuild intero. Is it going to to that for every project???
I do not see that rebuild in the log above that sentence. FYI: intero gets build per project because it has to be build with same GHC version as Haskell project. Once it is build, it does not get rebuild each time project is opened.
But anyways, it looks like most of the issues can be solved by setting ghc options in global stack config, project local stack config or cabal file. The plugin will not be changed to change any of the user it's files.
Also for now the plugin only support Haskell Stack projects. Including the way it's behaving. So Stack projects use GHCs which are installed by Stack otherwise it's getting too complicated to make the plugin solid in general. For example, a user can have multiple Haskell project with each a different Stackage resolver. It is already complicated to get it working on WIndows, Linux, Mac and with with Nix. Besides may other problems... Eventually I want to replace intero by some other Haskell backend and support for Cabal/Nix projects. But stack is very useful for installing Haskell tools.
I still want to help you but you have to be specific in what I can do for you. When you need ghc-options to be passed to installation of the Haskell tools, no problem. Same for building the project and intero. But solution seems to be in setting those ghc-options in stack and/or cabal config files. My mac uses brew so I can not reproduce your issues.
mouse07410
commented
5 years ago I have read your comments a couple of times but it's all getting too confusing for me...
It is even more confusing to me. ;-)
Mainly because I don't have a good grip on the ecosystem - some packages are built by cabal, some - by stack, each of these two "groups" has its own rules about what GHC to select. ~/.cabal/config.platform and ~/.stack/config.yaml clearly stated to use system GHC, and ignore the checks - but in some cases (your plugin, for example) that statement was ignored, and another GHC was downloaded and used.
So now I need to figure how to untangle this mess. What I'm leaning to now is removing my modified compiler altogether. If I have to use the "unmodified" (the original) one for anything at all, then presence of two differently-configured GHC compilers is a big problem. Then, I'd have to nuke my current cabal and stack databases, and update them a-new, with the GHC from Haskell Platform. Of course, I'll also need to make sure the configuration for all of these has the appropriate ghc-options: to work-around the libiconv.dylib issue.
I'm still in the process of figuring out the least damaging way of accomplishing the above.
To the best of your knowledge, which of the following directories can I delete
I do not understand why you want to delete files...
Because there are negative consequences of two GHC compilers being used - and I need to eradicate them.
I will not ask why not use
brew:-)
There are reasons, besides being reluctant to change everything this machine had since 2011. ;-)
AFAIK most of mac developers use brew, including me. (I also use Ubuntu, btw)
Not really. And the amount of packages that Macports serves is about 3 times greater than what Brew has, AFAIK. But that's not the main factor in my case.
FYI: intero gets build per project because it has to be build with same GHC version as Haskell project...
Ah... I did not realize that. But if several projects are built with the same GHC - would they share the same intero? Or would each project still build its own copy?
But anyways, it looks like most of the issues can be solved by setting
ghcoptions in global stack config, project local stack config or cabal file.
That's what I'm currently experimenting with - trying to find whether there are some config parameters for cabal, stack, and GHC invocations, that would work for all Haskell projects on my machines, regardless of whether they are created/edited by IntelliJ, or manually.
The plugin will not be changed to change any of the user's files
What about files like package.yaml and stack.yaml that get created (presumably by stack) when the project is created with stack new my-project? And who creates my-project.cabal file in this case?
I still want to help you but you have to be specific in what I can do for you.
Believe me, I appreciate this!
When you need
ghc-optionsto be passed to installation of the Haskell tools, no problem. Same for building the project and intero
Excellent, thank you!
I'm certain that if those options are necessary - they'll have to be the same for user projects, Haskell tools, and intero.
Would you consider adding a plugin config parameter that would contain ghc-options to be passed? Rather than, e.g., hard-coding them into the plugin itself?
But solution seems to be in setting those ghc-options in stack and/or cabal config files.
I do not know yet. I think adding the ability for the user to configure the plugin to pass ghc-options would be beneficial, regardless.
My mac uses brew so I can not reproduce your issues.
I'm happy for you - to be able to reproduce this issue regularly is not a pleasure! ;-)
mouse07410
commented
5 years ago I removed my modified compiler, and added the appropriate ghc-options: to ~/.cabal/config.platform and ~/.stack/config.yaml.
My projects seem to build fine, including installing intero. However, this plugin consistently fails to build intero, failing with unresolved names from libiconv:
Executing `/usr/local/bin/stack build intero` failed: /usr/local/bin/stack build intero: ghc-paths-0.1.0.9: configure -- While building package ghc-paths-0.1.0.9 using: /Users/uri/.stack/programs/x86_64-osx/ghc-8.6.3/bin/ghc --make -odir /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup -hidir /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup -i -i. -clear-package-db -global-package-db -package-db=/Users/uri/.stack/snapshots/x86_64-osx/lts-13.2/8.6.3/pkgdb -package-db=/Users/uri/src/p-test3/.stack-work/install/x86_64-osx/lts-13.2/8.6.3/pkgdb -hide-all-packages -package-id=Cabal-2.4.1.0-Df4rkGuWEtO4aZs4eesJ3r -package-id=base-4.12.0.0 -package-id=directory-1.3.3.0 -optP-include -optP/private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup_macros.h /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/Setup.hs /Users/uri/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup -threaded Process exited with code: ExitFailure 1 Logs have been written to: /Users/uri/src/p-test3/.stack-work/logs/ghc-paths-0.1.0.9.log [1 of 2] Compiling Main ( /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/Setup.hs, /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/Main.o ) /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/Setup.hs:29:18: warning: [-Wdeprecations] In the use of ‘rawSystemProgramStdoutConf’ (imported from Distribution.Simple.Program): Deprecated: "use getDbProgramOutput instead. This symbol will be removed in Cabal-3.0 (est. Mar 2019)." | 29 | libdir_ - rawSystemProgramStdoutConf (fromFlag (configVerbosity flags)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ [2 of 2] Compiling StackSetupShim ( /Users/uri/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/StackSetupShim.o ) Linking /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack14364/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup ... Undefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.12.0.0.a(iconv.o) (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding_closure, _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure ) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.12.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open) "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.12.0.0.a(iconv.o) (maybe you meant: _hs_iconv_close) "_locale_charset", referenced from: _localeEncoding in libHSbase-4.12.0.0.a(PrelIOUtils.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1)First, I'd much rather have an option to tell this plugin "please, use this intero instead of trying to rebuild it yourself".
Second, perhaps it fails because the way your plugin invokes stack to build intero, it ignores or doesn't use ~/.stack/config.yaml? Because that's the only reason I can think of why I can build intero, and your plugin cannot...
It tries (and fails!) to build a new intero for every project I create - though each and every one of them uses LTS-13.2, and GHC-8.6.3. And system-ghc: true is set in all the *.yaml files.
Could you do something about intero, please?
I take some of the above back. The original (unmodified) GHC fails to build intero when invoked from stack. Here's my invocation:
$ DYLD_LIBRARY_PATH=/usr/lib stack --system-ghc -v --extra-lib-dirs /opt/local/lib/liconv install intero 2>&1 | tee ~/src/intero-build.txtHere's the result:
intero-build.txt
Whatever seems to work for projects themselves, apparently does not work for intero.
mouse07410
commented
5 years ago @rikvdkleij would you consider adding support for cabal projects?
It would help if in the config for IntelliJ-Haskell I could specify flags to pass to stack when invoking it. Could you add this capability?
Also, it looks like it would help if I could force system-ghc: true for all the builds that this plugin initiates. Is it possible?
mouse07410
commented
5 years ago @rikvdkleij would you be able to notify me (e.g., by posting here) when you add the ability to pass flags/parameters to all stack invocations?
rikvdkleij
commented
5 years ago So one set of flags for all stack calls?
mouse07410
commented
5 years ago I am not certain, but it seems that if the plugin would allow the user to enter a string, which could be comprised of multiple arguments/parameters/flags, and pass that string to every stack invocation - it would at least allow for experimenting.
And yes, I'd probably start with just one "string" (one "set of flags"). It's possible that we'd need more - e.g., a set of flags for building projects, and another set of flags for building Haskell tolls, etc. - but at this time I think/hope that it wouldn't be necessary.
rikvdkleij
commented
5 years ago I'm busy with implementing that feature but problem is that not every stack command accepts the same options. For example, stack path does not accept --ghc-options. Most simple solution is to exclude stack path from adding the extra arguments.
rikvdkleij
commented
5 years ago Do you also need those extra option when building the project itself?
mouse07410
commented
5 years ago I'm busy with implementing that feature...
Thank you!
but problem is that not every stack command accepts the same options. For example,
stack pathdoes not accept--ghc-options. Most simple solution is to excludestack pathfrom adding the extra arguments.
I vote for your proposed solution, at least for stack path, where those extra arguments wouldn't make much sense.
Are you aware of other stack commands that your plugin invokes that also wouldn't need/accept extra arguments?
Also, I thought that your plugin would just pass just a user-supplied string, which wouldn't have to be a set of parameters for --ghc-options only, and is not restricted in general. It could be, for example, --only-snapshots --cabal-verbose. Or --ghc-options -optL=/usr/lib/libiconv.dylib. Or a combination of these two. Or something else altogether. But, again, not limited to only what could follow --ghc-options flag.
Do you also need those extra option when building the project itself?
I'm sure I do need extra options there. But I'm not 100% certain that I need those ones (it's just that so far the same options I needed for the stack to build Haskell tools, I needed for the stack to build my projects too). If it's not too much trouble, I'd probably have in the plugin configuration page (that IntelliJ IDEA shows) a few of "parameter string for X" for various X (building the project, building Haskell tools, something else that I don't know because of my limited experience with Haskell, etc.).
Also, I haven't figured out what to do with ghc-paths package, which kills the build of intero. Everything else (from what I tried so far, including quite a few of Hackage packages, etc) builds fine with stack, once I give those extra options. ghc-paths fails consistently. I opened an issue https://github.com/commercialhaskell/stack/issues/4504 on this, but opening an issue is not the same as finding a solution. :-(
So, maybe you could figure what to do with possible inability to build a "local" intero tool? The option I'd prefer would be for the plugin to accept that "OK, I cannot re-build intero the way I want - but the user tells me to use /Users/<name>/.local/bin/intero, so I will use it. And if it causes problems, the user is aware that his intero wasn't built by me for the snapshot..." This seems best to me, as I've got a few working intero builds (with cabal). Another possibility would be to teach the plugin to rely upon tools other than intero - I can't gauge the difficulty/complexity of this change.
rikvdkleij
commented
5 years ago Also, I thought that your plugin would just pass just a user-supplied string
Yes, that's what I'm doing. The point is that those options have to valid for every stack command that is executed.
rikvdkleij
commented
5 years ago About `ghc-paths', maybe the custom Setup.hs is the problem: http://hackage.haskell.org/package/ghc-paths-0.1.0.9/src/Setup.hs
But I do not know how to solve it...
rikvdkleij
commented
5 years ago I want to replace intero by another Haskell backend but that takes some time.
mouse07410
commented
5 years ago The point is that those options have to valid for every stack command that is executed
Oh yes, that's clear. Perhaps you want to put it in the README - that if a user decides to utilize that capability, he better consider and understand the consequences - such as that whatever he'd put there must be valid for all the stack invocations.
Possibly, having more than one "extra options" parameter - like, one for (user?) projects, one for building Haskell tools, etc. would mitigate this to an extent, as one would be able to configure two different sets of stack options...
About `ghc-paths', maybe the custom Setup.hs is the problem... But I do not know how to solve it...
I'm afraid that ghc-paths developer would have to be brought in for the fix, as it seems likely to me that his intervention (aka - change in the ghc-paths package itself) may be necessary.
I want to replace intero by another Haskell backend but that ta
Understandable. Also, if you have an idea what that backend is likely to be - perhaps it would pay for us to try it now, maybe directly from stack if the plugin isn't ready to be tested with it? So that we aren't hit by the same problem that hit us with intero?
rikvdkleij
commented
5 years ago Understandable. Also, if you have an idea what that backend is likely to be - perhaps it would pay for us to try it now, maybe directly from stack if the plugin isn't ready to be tested with it? So that we aren't hit by the same problem that hit us with intero?
https://github.com/mvoidex/hsdev is a good alternative. Switching to this one is a large change.
mouse07410
commented
5 years ago https://github.com/mvoidex/hsdev is a good alternative
I see. Tried to install it via stack right now. It seems to require about 100 dependencies, and the installation fails the same way it did with intero (but not on ghc-paths):
$ stack install hsdev --ghc-options -optL=/usr/lib/libiconv.dylib
happy-1.19.9: configure
integer-logarithms-1.0.2.2: download
async-2.2.1: download
hfsevents-0.1.6: download
async-2.2.1: configure
async-2.2.1: build
hfsevents-0.1.6: configure
hfsevents-0.1.6: build
integer-logarithms-1.0.2.2: configure
integer-logarithms-1.0.2.2: build
async-2.2.1: copy/register
hfsevents-0.1.6: copy/register
integer-logarithms-1.0.2.2: copy/register
Progress 4/75
-- While building package happy-1.19.9 using:
/usr/local/bin/ghc --make -odir /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup -hidir /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup -i -i. -clear-package-db -global-package-db -package-db=/Users/uri/.stack/snapshots/x86_64-osx/lts-13.2/8.6.3/pkgdb -package-db=/Users/uri/.stack/global-project/.stack-work/install/x86_64-osx/lts-13.2/8.6.3/pkgdb -hide-all-packages -package-id=Cabal-2.4.1.0-Df4rkGuWEtO4aZs4eesJ3r -package-id=base-4.12.0.0 -package-id=directory-1.3.3.0 -package-id=filepath-1.4.2.1 -optP-include -optP/private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup_macros.h /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/Setup.lhs /Users/uri/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup -threaded
Process exited with code: ExitFailure 1
Logs have been written to: /Users/uri/.stack/global-project/.stack-work/logs/happy-1.19.9.log
[1 of 2] Compiling Main ( /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/Setup.lhs, /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/Main.o )
/private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/Setup.lhs:48:22: warning: [-Wdeprecations]
In the use of ‘rawSystemProgramConf’
(imported from Distribution.Simple.Program):
Deprecated: "use runDbProgram instead. This symbol will be removed in Cabal-3.0 (est. Mar 2019)."
|
48 | let runProgram p = rawSystemProgramConf (fromFlagOrDefault normal (buildVerbosity flags))
| ^^^^^^^^^^^^^^^^^^^^
[2 of 2] Compiling StackSetupShim ( /Users/uri/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/StackSetupShim.o )
Linking /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack3719/happy-1.19.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup ...
Undefined symbols for architecture x86_64:
"_iconv", referenced from:
_hs_iconv in libHSbase-4.12.0.0.a(iconv.o)
(maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding_closure, _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure )
"_iconv_open", referenced from:
_hs_iconv_open in libHSbase-4.12.0.0.a(iconv.o)
(maybe you meant: _hs_iconv_open)
"_iconv_close", referenced from:
_hs_iconv_close in libHSbase-4.12.0.0.a(iconv.o)
(maybe you meant: _hs_iconv_close)
"_locale_charset", referenced from:
_localeEncoding in libHSbase-4.12.0.0.a(PrelIOUtils.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`clang' failed in phase `Linker'. (Exit code: 1)
$ You can observe that the -optL=... option was not passed to GHC, for some reason. And it took -optP=... from somewhere, which I did not put either in the config file, or in the command line.
BTW, when would your plugin with da0fe5b commit update would be available for IDEA? I checked today, but the version it offers is from Jan 09, 2019.
Update
It is crazy, but it seems that stack freezes flags - i.e., if the package on Hackage was built with flags XYZ, and you want to install it specifying different flags - it will ignore the flags you're giving and only use the original ones (and if they don't work in your environment - too bad).
rikvdkleij
commented
5 years ago Tried to install it via stack right now. It seems to require about 100 dependencies,
There is a cabal flag to not include hlint in the build.
You can observe that the -optL=... option was not passed to GHC, for some reason. And it took -optP=... from somewhere, which I did not put either in the config file, or in the command line.
Sorry, I can not help you with that.
BTW, when would your plugin with da0fe5b commit update would be available for IDEA? I checked today, but the version it offers is from Jan 09, 2019.
Did not release a new beta yet because busy with other changes which I want to include in the new beta.
rikvdkleij
commented
5 years ago @mouse07410 I will so release asap. Have some test issues.
mouse07410
commented
5 years ago I will so release asap.
Thank you!
Have some test issues.
Understandable. Your efforts are appreciated!
rikvdkleij
commented
5 years ago @mouse07410 Released new beta https://github.com/rikvdkleij/intellij-haskell/releases/tag/v1.0.0-beta41
mouse07410
commented
5 years ago Released new beta...
Excellent!! Do you have any idea how quickly IntelliJ is likely to make this update available via their Alpha update channel?
Thanks!
rikvdkleij
commented
5 years ago Can take some days.
You can also install beta from disk.
mouse07410
commented
5 years ago Installed the update.
First, now even the projects that used to build, fail at linking:
/usr/local/bin/stack build --exec p-test2-exe
Building all executables for `p-test2' once. After a successful build of all of them, only specified executables will be rebuilt.
p-test2-0.1.0.0: configure (lib + exe)
Using Parsec parser
Configuring p-test2-0.1.0.0...
Dependency base ==4.12.0.0: using base-4.12.0.0
Dependency base ==4.12.0.0: using base-4.12.0.0
Dependency p-test2 -any: using p-test2-0.1.0.0
Source component graph:
component lib
component exe:p-test2-exe dependency lib
Configured component graph:
component p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I
include base-4.12.0.0
component p-test2-0.1.0.0-5iqr50gtHYKaBkwainY1Q-p-test2-exe
include base-4.12.0.0
include p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I
Linked component graph:
unit p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I
include base-4.12.0.0
Lib=p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I:Lib
unit p-test2-0.1.0.0-5iqr50gtHYKaBkwainY1Q-p-test2-exe
include base-4.12.0.0
include p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I
Ready component graph:
definite p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I
depends base-4.12.0.0
definite p-test2-0.1.0.0-5iqr50gtHYKaBkwainY1Q-p-test2-exe
depends base-4.12.0.0
depends p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I
Using Cabal-2.4.0.1 compiled by ghc-8.6
Using compiler: ghc-8.6.3
Using install prefix: /Users/uri/.cabal
Executables installed in:
/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/bin
Libraries installed in:
/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/lib/x86_64-osx-ghc-8.6.3/p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I
Dynamic Libraries installed in:
/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/lib/x86_64-osx-ghc-8.6.3
Private executables installed in:
/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/libexec/x86_64-osx-ghc-8.6.3/p-test2-0.1.0.0
Data files installed in:
/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/share/x86_64-osx-ghc-8.6.3/p-test2-0.1.0.0
Documentation installed in:
/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/doc/p-test2-0.1.0.0
Configuration files installed in:
/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/etc
Using alex version 3.2.4 found on system at: /usr/local/bin/alex
Using ar found on system at: /opt/local/bin/ar
No c2hs found
Using cpphs version 1.20.8 found on system at:
/Users/uri/Library/Haskell/bin/cpphs
Using doctest version 0.16.0.1 found on system at:
/Users/uri/Library/Haskell/bin/doctest
Using gcc version 8.2.0 given by user at: /opt/local/bin/gcc
Using ghc version 8.6.3 given by user at: /usr/local/bin/ghc
Using ghc-pkg version 8.6.3 given by user at: /usr/local/bin/ghc-pkg
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.22.0 found on system at: /usr/local/bin/haddock
Using happy version 1.19.9 found on system at: /usr/local/bin/happy
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.67 found on system at: /usr/local/bin/hpc
Using hsc2hs version 0.68.5 found on system at: /usr/local/bin/hsc2hs
Using hscolour version 1.24 found on system at: /usr/local/bin/HsColour
No jhc found
Using ld found on system at: /opt/local/bin/ld
Using pkg-config version 0.29.2 found on system at: /opt/local/bin/pkg-config
Using runghc version 8.6.3 found on system at: /usr/local/bin/runghc
Using strip found on system at: /opt/local/bin/strip
Using tar found on system at: /usr/local/bin/tar
No uhc found
p-test2-0.1.0.0: build (lib + exe)
Component build order: library, executable 'p-test2-exe'
/usr/local/bin/ghc-pkg init .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/package.conf.inplace
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen
Preprocessing library for p-test2-0.1.0.0..
Building library for p-test2-0.1.0.0..
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build
/usr/local/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build -odir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build -hidir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build -stubdir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build -i -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build -isrc -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build -I/opt/local/include -I/usr/local/include -optP-include -optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/cabal_macros.h -this-unit-id p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /Users/uri/.stack/snapshots/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db /Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/package.conf.inplace -package-id base-4.12.0.0 -XHaskell2010 Lib Paths_p_test2 -O2 '-optL=/usr/lib/libiconv.dylib' -ddump-hi -ddump-to-file
Linking...
[(DefiniteUnitId (DefUnitId {unDefUnitId = UnitId
"base-4.12.0.0"}),DefaultRenaming)]
/opt/local/bin/ar -r -s .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/objs-6731/libHSp-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I.a .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Lib.o .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Paths_p_test2.o
ar: creating archive .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/objs-6731/libHSp-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I.a
/usr/local/bin/ghc -shared -dynamic -L/opt/local/lib -L/opt/local/lib/liconv -L/usr/lib -L/usr/local/lib '-dynload deploy' -optl-Wl,-rpath,/Library/Frameworks/GHC.framework/Versions/8.6.3-x86_64/usr/lib/ghc-8.6.3/base-4.12.0.0 -optl-Wl,-rpath,/Library/Frameworks/GHC.framework/Versions/8.6.3-x86_64/usr/lib/ghc-8.6.3/ghc-prim-0.5.3 -optl-Wl,-rpath,/Library/Frameworks/GHC.framework/Versions/8.6.3-x86_64/usr/lib/ghc-8.6.3/integer-gmp-1.0.2.0 -optl-Wl,-rpath,/Library/Frameworks/GHC.framework/Versions/8.6.3-x86_64/usr/lib/ghc-8.6.3/rts -this-unit-id p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I -hide-all-packages -no-auto-link-packages -no-user-package-db -package-db /Users/uri/.stack/snapshots/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db /Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/package.conf.inplace -package-id base-4.12.0.0 .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Lib.dyn_o .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Paths_p_test2.dyn_o -o .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/libHSp-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I-ghc8.6.3.dylib -O2 '-optL=/usr/lib/libiconv.dylib' -ddump-hi -ddump-to-file
/usr/local/bin/ghc-pkg recache '--package-db=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/package.conf.inplace'
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen
Preprocessing executable 'p-test2-exe' for p-test2-0.1.0.0..
Building executable 'p-test2-exe' for p-test2-0.1.0.0..
creating .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe
creating
.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp
/usr/local/bin/ghc --make -no-link -fbuilding-cabal-package -O -static -outputdir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -odir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -hidir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -stubdir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -i -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -iapp -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -I/opt/local/include -I/usr/local/include -optP-include -optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen/cabal_macros.h -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /Users/uri/.stack/snapshots/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db /Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/package.conf.inplace -package-id base-4.12.0.0 -package-id p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I -XHaskell2010 Paths_p_test2 app/Main.hs -threaded -rtsopts '-with-rtsopts=-N' -O2 '-optL=/usr/lib/libiconv.dylib' -ddump-hi -ddump-to-file
Linking...
/usr/local/bin/ghc --make -fbuilding-cabal-package -O -static -outputdir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -odir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -hidir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -stubdir .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -i -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -iapp -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen -i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe-tmp -I/opt/local/include -I/usr/local/include -optP-include -optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/autogen/cabal_macros.h -L/opt/local/lib -L/opt/local/lib/liconv -L/usr/lib -L/usr/local/lib -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /Users/uri/.stack/snapshots/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db /Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/package.conf.inplace -package-id base-4.12.0.0 -package-id p-test2-0.1.0.0-HVkftjOdn5xE80X7Ke7h1I -XHaskell2010 Paths_p_test2 app/Main.hs -o .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe -threaded -rtsopts '-with-rtsopts=-N' -O2 '-optL=/usr/lib/libiconv.dylib' -ddump-hi -ddump-to-file
Linking .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/p-test2-exe/p-test2-exe ...
Undefined symbols for architecture x86_64:
"_iconv", referenced from:
_hs_iconv in libHSbase-4.12.0.0.a(iconv.o)
(maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding_info, _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info )
"_iconv_open", referenced from:
_hs_iconv_open in libHSbase-4.12.0.0.a(iconv.o)
(maybe you meant: _hs_iconv_open)
"_iconv_close", referenced from:
_hs_iconv_close in libHSbase-4.12.0.0.a(iconv.o)
(maybe you meant: _hs_iconv_close)
"_locale_charset", referenced from:
_localeEncoding in libHSbase-4.12.0.0.a(PrelIOUtils.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`clang' failed in phase `Linker'. (Exit code: 1)
-- While building package p-test2-0.1.0.0 using:
/Users/uri/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.3 --verbose --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:p-test2 exe:p-test2-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Process finished with exit code 1The problem appeared to be --ghc-options -optL=/usr/lib/libiconv.dylib. When I replaced that with --ghc-options /usr/lib/libiconv.dylib, the project p-test2 built and ran again successfully.
Other projects also build OK, when I import them.
However, the plugin fails to create new projects:
It seems that different invocations of stack would require different parameters. Would it be possible to add a parameter string (like you've done) for every significant invocation? I can think of the following:
intero)rikvdkleij
commented
5 years ago The problem appeared to be --ghc-options -optL=/usr/lib/libiconv.dylib. When I replaced that with --ghc-options /usr/lib/libiconv.dylib, the project p-test2 built and ran again successfully.
I do not understand this. The second one does not seem to a valid ghc option. Maybe I have to put quotes around the value or make the setting only for --ghc-options instead of a general string which is passed to stack and then to ghc.
I can think of the following: Create a new Haskell project/module Import a Haskell project from sources Build Haskell components/packages (like intero) Build user project
Sorry. but that is unmaintainable. We have to find right solution for this issue...
What works and what works not without --ghc-options? I will also exclude stack new from passing the extra options.
And I suggest for make the extra setting a --ghc-options field in which I will put quotes around it.
Or maybe you have to put quotes around:
--ghc-options -optL=/usr/lib/libiconv.dylib
mouse07410
commented
5 years ago The problem appeared to be
--ghc-options -optL=/usr/lib/libiconv.dylib. When I replaced that with--ghc-options /usr/lib/libiconv.dylib, the projectp-test2built and ran again successfully.I do not understand this. The second one does not seem to a valid ghc option.
Yet it is correctly interpreted as an input for the linker, and passed to it correctly. While in the other case, the correct parameters are appended to the pre-defined ones, and so have no useful effect - the "wrong" library by this time has already been found, and the error has been thrown.
Maybe I have to put quotes around the value or make the setting only for
--ghc-optionsinstead of a general string which is passed to stack and then to ghc.
Please don't. This is something that I can experiment with, and a user would have no problem adding quotes - while it would be impossible to remove them if you put them in your plugin and they turn out interfering (as I suspect they would).
We have to find right solution for this issue...
That's what we're doing! ;-)
What works and what works not without
--ghc-options?
It looks like /usr/lib/libiconv.dylib has to be passed to the linker - via GHC - via stack. For my projects, I can arrange that by editing stack.yaml and package.yaml (and/or <project-name>.cabal). For the tools that stack builds, perhaps including (some?) dependencies, which do not take parameters specified in the project's stack.yaml, the plugin must pass them via that "extra parameters string".
I will also exclude stack new from passing the extra options.
Yes please - that seems a good start.
And I suggest for make the extra setting a
--ghc-optionsfield in which I will put quotes around it.
Please don't put quotes around it.
Or maybe you have to put quotes around:
--ghc-options -optL=/usr/lib/libiconv.dylib
I can experiment with this, but the problem seems to be not that this parameter didn't get passed (and it's passed single-quoted!), but that it's passed after all the other parameters, thus coming in too late.
Also, another related issue: it looks that when a Haskell project is opened, either stack or the plugin itself immediately begins (re-)building it - automatically. That's bad, because it doesn't give me the chance to edit/modify stack.yaml and other files. I'd like the plugin build the project only upon explicit command.
Also, it would be nice if there'd be an option to "Clean" the project without re-building.
Thanks!
rikvdkleij
commented
5 years ago Also, another related issue: it looks that when a Haskell project is opened, either stack or the plugin itself immediately begins (re-)building it - automatically.
That's on purpose to be sure that all dependencies are build otherwise REPLs will not start.
mouse07410
commented
5 years ago Then perhaps do not (or make an option to not) start REPL automatically, because building dependencies with wrong or incomplete parameters is not good, regardless.
rikvdkleij
commented
5 years ago In beta42 the extra options are not passed to stack new anymore,
mouse07410
commented
5 years ago Thanks - will try it as soon as it's available on IntelliJ Alpha update channel.
mouse07410
commented
5 years ago With stack - same problem. There seems to be no way to pass flags to building ghc-paths package, so building intero (which depends on ghc-paths) always fails.
I suspect it's the problem with stack itself, probably a design issue.
Could you please stop automatic build of the project? Or at least give the user config option to disable automatic build?
Also, since cabal appears to work far more reliably (for me, at least) - would it be at all possible to use cabal instead of stack?
P.S. My sample projects seem to build fine, if you don't count wasting approximately 1GB of disk space per two simple (a-la "Hello World") projects, thanks to stack and its local caching of everything.
rikvdkleij
commented
5 years ago With stack - same problem. There seems to be no way to pass flags to building ghc-paths package, so building intero (which depends on ghc-paths) always fails.
So I can remove the settings field to pass options to stack commands?
Could you please stop automatic build of the project? Or at least give the user config option to disable automatic build?
That does not solve your problem. Stack is also used for building intero, installing tools and running the REPLs with Intero. Intero only works for stack projects.
Also, since cabal appears to work far more reliably (for me, at least) - would it be at all possible to use cabal instead of stack?
Yes, that would be solution together with replacing Intero by another Haskell backend. But this takes some development effort. Btw, I already did some preparations to decouple features from stack but still it's a lot of work.
P.S. My sample projects seem to build fine, if you don't count wasting approximately 1GB of disk space per two simple (a-la "Hello World") projects, thanks to stack and its local caching of everything.
The nice thing of using stack is that one does NOT need a globally installed GHC. So every project can have a different GHC version. With Cabal one has to use for example Nix to prevent globally installed GHC. I do not want and need a globally installed GHC.
rikvdkleij
commented
5 years ago Alternative way for installing GHC, https://github.com/haskell/ghcup
mouse07410
commented
5 years ago So I can remove the settings field to pass options to stack commands?
Please don't. This is a very useful feature (regardless of the backend type, BTW), even if there are a few packages (like ghc-paths) that seem "immune" to it. Thankfully, the majority of the packages can benefit from this feature.
Could you please stop automatic build of the project? Or at least give the user config option to disable automatic build?
That does not solve your problem. Stack is also used for building intero, installing tools and running the REPLs with Intero. Intero only works for stack projects.
I hear you, but don't fully understand: on my setup there's no way to build either intero or ghc-paths (which intero depends on) using stack. So your plugin fails to build intero. Yet my projects build and run successfully under your plugin. It seems that building intero doesn't help and isn't needed..? (I'm sure I'm missing something here, but haven't figured out what yet.)
My sample projects seem to build fine, if you don't count wasting approximately 1GB of disk space per two simple (a-la "Hello World") projects, thanks to stack and its local caching of everything.
The nice thing of using stack is that one does NOT need a globally installed GHC. So every project can have a different GHC version.
This is a matter of preference. To me GHC "sprawl" is not nice. I'm coming from a "disciplined software design" background, where interfaces are thought over carefully, and then don't change like daily temperatures. I do a lot of programming, run a lot of projects (some in Haskell, the majority in other languages - as you can guess, I'm paying for IntelliJ license not via Haskell projects ;), and have no disk space to waste on useless replications (especially with the magnitude of extra space that stack seem to require to replicate so much of the Haskell environment).
With Cabal one has to use for example Nix to prevent globally installed GHC.
Yes, this is one reason among many why I prefer Cabal oner stack. And instead of preventing use of the globally installed GHC, I'm trying to enforce it where I can.
I do not want and need a globally installed GHC.
And I'm exactly opposite - I do want and need a globally installed GHC.
Alternative way for installing GHC, https://github.com/haskell/ghcup
Yes, I know. I'm discussing with developers the options/capabilities. In general, it isn't ready yet for MacOS the way I'm using it - and it won't help with my problems anyway, because the "main" GHC works fine (and so does Cabal) on my machine. It's when stack starts downloading its own copies of GHC and insists on re-building packages like ghc-paths with their own flags ignoring the flags I'm passing to it, that things fall apart.
Also, since cabal appears to work far more reliably (for me, at least) - would it be at all possible to use cabal instead of stack?
Yes, that would be solution together with replacing Intero by another Haskell backend. But this takes some development effort. Btw, I already did some preparations to decouple features from stack but still it's a lot of work.
I realize that enabling Cabal as a build env alternative is a significant effort, and could take considerable time. I still welcome that development. Thank you!
rikvdkleij
commented
5 years ago with their own flags ignoring the flags I'm passing to it, that things fall apart.
I still wonder if it makes sense to have setting to add extra options to stack commands because it sometimes works and sometimes not. Very confusing for future users.
rikvdkleij
commented
5 years ago and have no disk space to waste on useless replications (especially with the magnitude of extra space that stack seem to require to replicate so much of the Haskell environment).
There is only GHC version per computer (when needed) :smile:
(I'm sure I'm missing something here, but haven't figured out what yet.)
A lot of features depend on running the stack repl with intero as plugin. So stack repl to have a repl in the context of the project and intero for features like definition location and type info based on location. So what helps for you is that I add another setting in which user can point to alternative location of intero , which has the risk that the alternative intero is build with different GHC version as project.
Can do the same for the Haskell tools binaries which has the risk that supports breaks because the API is not compatible with what plugin is expecting.
mouse07410
commented
5 years ago with their own flags ignoring the flags I'm passing to it, that things fall apart.
I still wonder if it makes sense to have setting to add extra options to stack commands because it sometimes works and sometimes not. Very confusing for future users.
and have no disk space to waste on useless replications (especially with the magnitude of extra space that stack seem to require to replicate so much of the Haskell environment).
There is only GHC version per computer (when needed) 😄
There should be only one GHC version - but in my experience, stack multiplies them like viruses. 😱😤
Not to mention all the other crap stuff that it pulls in. Overall, I've had a few toy projects that pulled over 1GB of stuff. By my book - absolutely intolerable.
So what helps for you is that I add another setting in which user can point to alternative location of
intero, which has the risk that the alternativeinterois build with different GHC version as project.
YES! This risk is perfectly acceptable to me, and would be stated by the developer in the README to warn those who shouldn't be doing that.
Can do the same for the Haskell tools binaries which has the risk that supports breaks because the API is not compatible with what plugin is expecting.
YES! Yes, please! Note, that IntelliJ already does this for most everything it provides - it detects what it can, and allows you to override those locations. So, for example, I set it to use my own Maven.
Just expose the defaults, allow user to override them, and state that risk in the README. E.g., telling the user that he shouldn't modify the defaults unless he both understands well what the consequences could be, and has a good reason to diverge from those defaults.
Maybe in that case, automatic build upon project import won't be necessary? And/or maybe it could be controlled by a config option, like "Do not build the project automatically"?
rikvdkleij
commented
5 years ago AFAIK this one can be closed.
mouse07410
commented
5 years ago Yeah, it's fine.
One problem - the current plugin does not support operations like "stack clean" (which is necessary to deal with cases when, e.g., there are artifacts stuck in the project that prevent it from running correctly). There's no way to request such an operation, and no way to prevent plugin from forcing the executable (that it consists the right one).
MacOS Mojave 10.14.2, IntelliJ IDEA 2018.3.3, GHC-8.6.3 (rebuilt - see below)
My systems have Macports installed. That makes it impossible to link static Haskell executables, because Macports introduced its own copy of
libiconv.dylibthat mangles function names - which in turn makes it impossible to link anything withlibHSbase.a(see https://trac.macports.org/ticket/57821).Here's what the failure looks like:
And here's the log file it refers to: hoogle-log.txt
There are two solutions:
/opt/local/binthat precedes/usr/local/binon the PATH), so it is linked against Macports, so it'slibHSbase.ais happy with Macports-providedlibiconv.dylib./usr/lib/libiconv.dylibto each and every invocation of GHC.My
~/.cabal/config.platformand~/.stack/config.yamlrequire system-ghc, but apparently this plugin doesn't honor it, and when it downloads a "standard" resolver with its own GHC - that GHC fails the link phase onlibiconv.dylib.What I'd like to see in this plugin: