search

haskell / haskell-ide-engine

The engine for haskell ide-integration. Not an IDE
BSD 3-Clause "New" or "Revised" License
2.38k stars 211 forks source link

Could not obtain flags for: "Setup.hs" #1650

Open jneira opened 4 years ago

jneira commented 4 years ago

The workaround could be creating a implicit configuration with a hie.yaml file to make hie ignore Main.hs

More drastic one: if Setup.hs is the default one, like this:

import Distribution.Simple
main = defaultMain

and you build-type is simple (the default one) in your <pkgname>.cabal file, afaik you can delete it.

fendor commented 4 years ago

I dont think you may delete it. Cabal still needs it to build stuff, iirc.

Other work-around that got into my mind and I havent tested: Direct arguments:

cradle:
  direct:
    arguments:
    - "-package Cabal-3.0.0.0"
    - "-package base-4.12.0.0"
jneira commented 4 years ago

I dont think you may delete it. Cabal still needs it to build stuff, iirc.

afaik cabal and stack(via cabal-simple i guess) generates a Setup.hs on the fly if the build-type is simple and there is no a real file (i've just tested deleting the Setup.hs in a cabal and stack projects and they build fine). But the file is regenerated under some circunstances (not always) so your workaround is better.

fendor commented 4 years ago

This work-around might not actually work, I did not try, yet :)

jneira commented 4 years ago

Finally the error was throwed cause hie was called without --lsp and it tries to load everything in the project, including Setup.hs. So this error should not be showed if you start hie correctly and you dont open Setup.hs in the editor.

fendor commented 4 years ago

I mean, this issue can still be a feature request to load Setup.hs into the editor?

jneira commented 4 years ago

Uh, i thought abot that option but given it is handled by cabal in a exceptional way i guess it would be tricky: afaik cabal does not expose its build (or does it? dont know tbh) and we will have to replicate manually the ghc flags cabal uses to compile/interpret it, including the setup-config if the build-type is custom (see #1638)

Maybe cabal-helper could do that? But more important, does it worth the effort?

jneira commented 4 years ago

Maybe we should skip Main.hs when loading everything? At least until hie is able to handle it

fendor commented 4 years ago

Cabal-Helper could be able to do it (not yet, but maybe in the future), or at least, we should modify Cabal to expose an interface to load the Setup.hs

Problem with skipping Setup.hs:

I think a custom hie.yaml for whoever is really bothered by it is the best work-around for now.

mouse07410 commented 4 years ago

@fendor a stupidly naive question: can I put in in one hie.yaml file entries for both Cabal and Stack?

Something like

cradle:
  stack:
  cabal:

Or for a project that should support builds by both Stack and Cabal I need two files - cabal.project, and hie.yaml configured for Stack?

fendor commented 4 years ago

No, you can not add entries for both build tools, since hie would then not know what to use! In this repo, we have hie.yaml.cbl and hie.yaml.stack which you rename to hie.yaml to use the appropriate build tool!

You only need a hie.yaml for cabal, the explicit cabal.project is optional and only used to determine, whether you should use stack or cabal if there is no hie.yaml.

mouse07410 commented 4 years ago

@fendor

No, you can not add entries for both build tools, since hie would then not know what to use!

That's a pity.

You only need a hie.yaml for cabal, the explicit cabal.project is optional and only used to determine, whether you should use stack or cabal if there is no hie.yaml.

Hmm... According to this, HIE should by default (if none of these files is present) use Stack (no ambiguity, no confusion, nothing points at Cabal - therefore use Stack), and only resort to Cabal if (a) hie.yaml says so, or (b) cabal.project is present.

In my experience, HIE got confused and failed to properly proceed when none of the above was present (though the project dir had both stack.yaml and <project>.cabal), and worked correctly (I don't know whether it gave preference to Stack or Cabal, nor do I care - unless you tell me it's important) when both were present.

Before I saw your reply here, I decided to experiment, and created hie.yaml with the following content:

cradle:
  stack:
  cabal:

HIE (invoked by VS Code) appeared to perform flawlessly, not displaying any confusion whatsoever. Then I successfully built this project by Stack (both "run" and "test") and Cabal (again, both "run" and "test").

What am I missing???

fendor commented 4 years ago

Hmm... According to this, HIE should by default (if none of these files is present) use Stack (no ambiguity, no confusion, nothing points at Cabal - therefore use Stack), and only resort to Cabal if (a) hie.yaml says so, or (b) cabal.project is present.

No, default is not stack but direct ghc if there is no file whatsoever. See for https://github.com/haskell/haskell-ide-engine#project-configuration for details

Before I saw your reply here, I decided to experiment, and created hie.yaml with the following content:

then hie-bios is not strict enough when it comes to parsing. However, it will still be one of two, not both.

mouse07410 commented 4 years ago

then hie-bios is not strict enough when it comes to parsing.

Is it likely that it would remain so?

However, it will still be one of two, not both

What would be the impact of this? HIE doesn't build the project by itself, right? So, e.g., if it picks Stack but the project was actually intended for Cabal - what would be the harm? My use case - HIE as a part of VS Code-based IDE. How to actually build the project - ultimately I decide, and VS Code plugin(s) provides convenience buttons and task scripts (which again, I edit) to do that.

fendor commented 4 years ago

Is it likely that it would remain so?

I dont see a reason why it should, it is an implementation detail.

What would be the impact of this? HIE doesn't build the project by itself, right? So, e.g., if it picks Stack but the project was actually intended for Cabal - what would be the harm? My use case - HIE as a part of VS Code-based IDE. How to actually build the project - ultimately I decide, and VS Code plugin(s) provides convenience buttons and task scripts (which again, I edit) to do that.

I am not sure what you are trying to ask and, moreover, this is completely unrelated to the issue, right? If you have questions in particular, please open another issue, dont hijack the issue described here, which is about opening a projects' Setup.hs file.

Regarding your question: dont use HIE to build your project, since it changes options to give a better developer experience. If you build a project with stack intended for cabal, the build will either fail or succeed, depending on whether stack build would succeed.

mouse07410 commented 4 years ago

If you have questions in particular, please open another issue, dont hijack the issue described here...

Good point, thanks. Done: https://github.com/haskell/haskell-ide-engine/issues/1667

Although, I experienced the problem described here, which was remedied by adding hie.yaml. So, arguably, the questions regarding the content of that file are relevant to this issue. ;-)

drewboardman commented 4 years ago

If you have questions in particular, please open another issue, dont hijack the issue described here...

Good point, thanks. Done: #1667

Although, I experienced the problem described here, which was remedied by adding hie.yaml. So, arguably, the questions regarding the content of that file are relevant to this issue. ;-)

What hie.yaml did you use? I'm just starting to see this error now. I'm using nix with the all-hies cached binaries. I have both 864 and 865 installed.

I'm using coc.nvim, and starting hie with with --lsp flag as well.

{
  "languageserver": {
    "haskell": {
      "command": "hie-wrapper",
      "args": ["--lsp", "--debug"],
      "rootPatterns": [
        "stack.yaml",
        "cabal.config",
        "package.yaml"
      ],
      "filetypes": [
        "hs",
        "lhs",
        "haskell"
      ],
      "initializationOptions": {
        "languageServerHaskell": {
          "hlintOn": false,
          "completionSnippetsOn": true
        }
      }
    }
  }
}

Here is the output of my hie-wrapper --debug.

###################################################

Cradle: Stack project
Project Ghc version: 8.6.4
Libdir: Just "/home/drew/.stack/programs/x86_64-linux/ghc-tinfo6-8.6.4/lib/ghc-8.6.4"
Searching for Haskell source files...
Found 3 Haskell source files.

###################################################

Found the following files:

/drew/code/fooProject/src/Report.hs
/drew/code/fooProject/app/Main.hs
/drew/code/fooProject/Setup.hs

...
...  <--- truncated logs
...

2020-02-26 10:10:26.251837807 [ThreadId 4] - Fail on cradle initialisation: (ExitFailure 2)["Could not obtain flags for: \"Setup.hs\".","","This module was not part of any component we are aware of.","","Component: ChLibName ChMainLibName with source directory: [\"src\"]","Component: ChExeName \"fooProject-exe\" with source directory: [\"app\"]","","","To expose a module, refer to:","https://docs.haskellstack.org/en/stable/GUIDE/","If you are using `package.yaml` then you don't have to manually expose modules.","Maybe you didn't set the source directories for your project correctly."]

###################################################
###################################################

Dumping diagnostics:

/drew/code/fooProject/src/Report.hs: FAILED
        "can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)"
/drew/code/fooProject/app/Main.hs: FAILED
        "cannot satisfy -package-id fooProject-0.1.0.0-5ysGVNNfkt11rbkMkwZbMx\n    (use -v for more information)"
/drew/code/fooProject/Setup.hs: FAILED
        Fail on initialisation for "/drew/code/fooProject/Setup.hs". Could not obtain flags for: "Setup.hs".

Note: loading of 'Setup.hs' is not supported.
fendor commented 4 years ago

@drewboardman With messages such as "can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)", your problem is probably not related to hie.yaml, rather your hie installation or some problems with ghc. I figure stack build and stack repl works? If it does, you can create a hie.yaml with 

cradle:
  stack:

Also, this is still hijacking the issue. Just because the issue occurs in your problem, does not mean it is related.

drewboardman commented 4 years ago

@drewboardman With messages such as "can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)", your problem is probably not related to hie.yaml, rather your hie installation or some problems with ghc. I figure stack build and stack repl works? If it does, you can create a hie.yaml with

cradle:
  stack:

Also, this is still hijacking the issue. Just because the issue occurs in your problem, does not mean it is related.

I appreciate the response. The issue was indeed fixed by using an hie.yaml, but like the responses above - it seems like you shouldn't need a config file unless you're multi-cradle.

mouse07410 commented 4 years ago

The issue was indeed fixed by using an hie.yaml

I'm afraid it wasn't. Showed up on a test-project (mkdir h-tst1 && cd h-tst1 && cabal init), if I touch/open Setup.hs with the editor.

With everything current, and hie built from the current GitHub repo:

Screen Shot 2020-06-26 at 06 40 31

hie.yaml:

cradle:
  cabal:

Main.hs:

module Main where

main :: IO ()
main = putStrLn "Hello, Haskell!"

h-tst1.cabal:

cabal-version:       2.2
-- Initial package description 'h-tst1.cabal' generated by 'cabal init'.
-- For further documentation, see http://haskell.org/cabal/users-guide/

name:                h-tst1
version:             0.1.0.0
-- synopsis:
-- description:
-- bug-reports:
license:             MIT
license-file:        LICENSE
-- author:              
-- maintainer:          
-- copyright:
-- category:
extra-source-files:  CHANGELOG.md

executable h-tst1
  main-is:             Main.hs
  -- other-modules:
  -- other-extensions:
  build-depends:       base ^>=4.13.0.0
  -- hs-source-dirs:
  default-language:    Haskell2010

Right now I don't use Setup.hs - it was a "gitf" from cabal init, so probably can just use the workaround from https://github.com/haskell/haskell-ide-engine/issues/1650#issuecomment-584482263 and avoid opening Setup.hs. But if I need to use it in the future - what should I do?

fendor commented 4 years ago

@mouse07410 It is currently not supported to open the Setup.hs file which is special to the Cabal (not cabal-install, nor stack) build system. That's why it exists in both cabal-install and stack projects.

If you really need to work on it, you are currently out of luck with hie/hls/ghcide.

An untested work-around I thought about could be (same as here: https://github.com/haskell/haskell-ide-engine/issues/1650#issuecomment-584116019):

cradle:
  multi:
    - path: ./Setup.hs
      config:
        cradle:
          direct:
          - "-package Cabal"
          - "-package base"
    - path: ./
      config:
        cradle:
          cabal:
mouse07410 commented 4 years ago

It is currently not supported to open the Setup.hs file . . . . . If you really need to work on it, you are currently out of luck with hie/hls/ghcide.

Ah, OK. Then I'm not missing anything. Thankfully, I don't really need it right now.

An untested work-around I thought about . . .

Thanks! Will try it and report.

Update

Doesn't seem to work:

Screen Shot 2020-06-26 at 07 14 50

fendor commented 4 years ago

You made me look...

The error is in the hie.yaml, it should be:

cradle:
  multi:
    - path: ./Setup.hs
      config:
        cradle:
          direct:
            arguments:
              - "-package Cabal"
              - "-package base"
    - path: ./
      config:
        cradle:
          cabal:

Then it actually works

mouse07410 commented 4 years ago

Thank you!! Now there's a working workaround! ;-)

Appreciate!