-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to get the typechecker plugin into kdb #2180
Comments
As far as I know there is no |
Yes. you need the haskell binding (It has quite some deps: https://www.libelektra.org/bindings/haskell), then the haskell plugin (again deps: https://www.libelektra.org/plugins/haskell) so that you can finally enable the typechecker plugin. @e1528532 Can you update the docu of the typechecker which parts are needed so that it will work? And why is |
This installation process is extremely cumbersome, especially for linux. You require
What is this? Where can i find it? My cmake version: |
What linux do you use that still only has 7.x? Is it possible that you have multiple versions of ghc installed and that cmake picks the wrong one? The first bug you describe is probably really a bug, i guess older ghc versions don't output something for the --print-target-platform command line parameter and thus replace complains. will fix. The second issue also indicates that it probably picks some old ghc version that doesn't support the keywords i need, even not those to fetch its version number. What happens if you add something like I agree that having < 8.4 unsupported is annoying but newer versions of a libraries used are not supported on 8.0.1 due to haskell-hint/hint#63 so until this is fixed i can't support newer versions unfortunately. |
Linux Mint 18.2 which uses the xenial ubuntu repository.
Yes, it does. It tries to use |
ok i will try to improve the cmake file to detect versions 7.x and give appropriate hints in that case. As far as i know cmake caches the programs it found though so that could be a reason why it resumed to use 7.x. |
After cleaning the build directory it works. But now when calling
|
I assume you have installed the sandbox with the dependencies? what happens if you cd to |
Yes it doesnt fail. it writes
|
Ok, i called PS: I needed to do the same in src/plugins/typechecker |
Alright ... here is your next problem ...
|
Ok so the bindings seem to build correctly. Next step in debugging this: Whats the output of |
|
That file should be generated in A solution that doesn't require redoing everything would be deleting the haskell-related things from the build directory, so |
Typechecker.dyn_hi Typechecker.dyn_o Typechecker.hi Typechecker.o Typechecker_stub.h Still receiving the error
|
Can we maybe reproduce this problem in a docker image? Would be also nice to get some more distros into our build server, seems like there are some important differences after all, at least in Haskell. |
@e1528532 any progress here? Actually we even have a Docker image for xenial: scripts/docker/ubuntu/xenial/Dockerfile so you would just need to add the Haskell stuff. |
@Piankero have you tried my suggestion with deleting the haskell things in the build folder any calling cmake again? Did that help? @markus2330 i can try to setup haskell on xenial yes, but i'd need to use a different version of ghc if xenial only delivers 7.x. I need to use 8.0 or higher because 7.x lacks the required extension, is unsupported by a number of libraries like |
@e1528532 using the same compiler as @Piankero used. @Piankero can you be more specific which versions you use, what commands you typed and so on. |
No, it did not help. I even removed the whole build folder and tried it again without success.
|
Still not answered. The version of cabal, ... might be interesting. And where did you get GHC from? Seems like Xenial only has GHC 7? Reproducing in a docker image seems like best way forward. There are many things that might be broken locally (e.g. HASKELL_SHARED_SANDBOX could be set and contain garbage?) |
Right this is also possible. If you created the HASKELL_SHARED_SANDBOX with ghc7 beforehand i can imagine that there are some incompatibilities with ghc8 then. As far as i've understood you manually installed ghc8.2.2 then in xenial? If so, i will try to setup a docker image that uses that version and build the project on our xenial image as well. |
Also, the cabal version used is important i think, not sure if the versions shipped with ghc7 work well, i assumed 8.0.1 as present on stretch as the minimum that corresponds to cabal 1.24.1.0 as stated in the haskell binding dependencies. |
what are the versions of alex, c2hs and happy? If you install them via cabal, ensure that ghc8 is used (and an appropriate cabal version) |
Interesting, tried your setup in a docker container (xenial with ghc7.10) and when i configure the project i get: i can't check for exclusion of the bindings in a plugin in a good way. It would be great if i can have plugins depend on bindings, but i don't like working with cmake ;) as a workaround i've added the version check to LibAddHaskellPlugin as well.
Can't reproduce this unfortunately, but i've added a (blind) workaround to the xenial branch |
Versions:
I did not install via cabal as your tutorial states it should be installed via the package manager. I downloaded ghc8.2 via stack and set my PATH in zshrc to the binary. The same for the |
Ok thanks, apparently these are also older versions than i've tested it with. So it could be that for instance the older c2hs version doesn't correctly compile the bindings, leading to the missing dependency error you encounter. Lets look what happens in the PR that adds ghc to the xenial docker image. |
I recreated the whole sandbox, installed happy/c2hs/alex via cabal to have more recent versions and manually set the path to the cabal sandbox bin directory. I still receive errors.
I manually went into the directory build/src/plugin/haskell and called After cleaning the build directory again I am now stuck here:
This typechecker plugin is really getting annoying ... |
i feel you, getting this whole compilation going with cabal and cmake was/is a pain. i still consider switching to stack instead of cabal, though it implies an extra tool i think it could help making this more stable. i really wonder whats the big difference in your setup. the xenial docker image succeeds to compile everything so it shouldn't be impossible with that setup. But for now i suggest that you leave it be i try to find a good solution. |
I cannot get the typechecker plugin running.
I used
What am I doing wrong?
The text was updated successfully, but these errors were encountered: