Build HLS dynamic executables
HLS should be compiled with -dynamic in all platforms except Windows, in order to avoid issues with Template Haskell and the eval plugin
Activity
added scopeupstream label
You'll be happy to know that cabal.project conditionals are being worked on: https://github.com/haskell/cabal/pull/7783 :)
but cabal.project
*.cabaldoes thoughYou can also add flags in the cabal file that trigger these ghc options.
Edited by Julian Ospald-
Also... I just tried. It doesn't work with
cabal v2-build, because you also have to install the libraries of the plugins first viacabal v2-install, butv2-installhas different semantics thanv2-buildin the sense that it caches only by PVP version and flags, not tarball hashes (remember: v2-instaall does an sdist before compilation and also ignorescabal.projectmostly, which is another problem). So you could get cache hits where you don't want them.A way around that would be to set a clean
store-dir, but that will increase build times a lot.Edited by Julian Ospald -
It's not hardcoding if it's behind a cabal flag.
Also, enabling it in cabal.project will make it harder to disable it. And as I just pointed out, there are problems with it as well.
Edited by Julian Ospald and hope that -dynamic will be sensibly ignored in Windows
i am afraid that might be not the case, see https://github.com/haskell/haskell-language-server/issues/2048 from when we tried to enable dynamic linking in stack (i think it is probably cabal could suffer it, not tested it though)
Edited by Javier Neira
could be another alternative use a custom cabal.project.local with dynamic enabled and use it with
ghcup compile hls --cabal-project-local=/path/to/cabal-dynamic.project.local?Edited by Javier NeiraOpened https://github.com/haskell/haskell-language-server/issues/2245 to discuss the HLS change.
Let's scope this issue down to a change in ghcup that adds the flag
--enable-executable-dynamicto thecabal installcommand, or similarIirc @maerwald want to avoid have to pass args to the cabal invocation so he added the cabal.project.local to accomplish it
A possible generic way to do it could be add some way to pass args to cabal:
- with a dedicate cli option
--build-options="--enable-executable-dynamic"- or take all args after
--as options to be passed to cabal
- or take all args after
- and run
cabal configure <options>to create acabal.project.localon the fly before doing the build
It could be extended to all tools compilable with ghcup. It would be somewhat incompatible with
--cabal-project-localas afaikcabal configurewould overwrite it. Thoughts @maerwald?Edited by Javier Neira- with a dedicate cli option
Maybe relevant: https://github.com/haskell/cabal/issues/7236
cabal installignoring--enable-executable-static(but it is honoured bycabal build) marvellousFWIW: Ran into this issue, would like to voice support for proposed changes.
It's easy enough to fix if you pass manual overrides, but it's effected enough people that IMO the explicit option should mostly serve as a warning sign for folks to catch this early before sinking time debugging.
If I see there's an option in
ghcupto compile HLS dynamically, particularly if it has[RECOMMENDED]or similar and a description of what problems it can cause, then perhaps that avoids me filing issues and wasting other people's time.See below for large list of
openHLS issues returned with search:static OR dynamic OR linking(which should be an approximation, probably few false-positives):This comment provides a short + solid analysis of issue, and the Docker image it was being run in to sum things up:
And another example:
If the change would be backwards compatible, I think there's a good argument for making it a default.
If it isn't, then a descriptive flag and companion
bootstrapoption would be greatly appreciated
Edited by Gavin Ray@GavinRay97 hi! it seems to me the comment belongs more to the hls project issue tracker. ghcup distributes the prebuilt binaries generated in the hls repo (with
ghcp install hls) and additionally it offers the option of build hls from source withghcup compile hls. So ghcup itself does not decide how are built hls binaries (like it does not decide how ghc binaries are built)This issue is requesting make slightly easier built hls dinamically linked with
ghcup compile hls.About make dinamically linked executables the default ones i am gonna respond in the hls issue if you dont mind: https://github.com/haskell/haskell-language-server/issues/1431#issuecomment-964493925 Thanks!
Edited by Javier NeiraUnfortunately it seems
ghcup compile hlscant be used right now to build dynamically hls, see https://github.com/haskell/haskell-language-server/issues/1431#issuecomment-964660981 and subsequent comments aboutAn alternative could be:
- return to use
cabal installforghcup compile hls(it would fix #251 as well) - use a dedicated cabal store in a temp dir for building hls as proposed by @maerwald to workaround the cabal install bug related wih cache invalidation. But only when hls is building from a git checkout (not from hackage) as afaiu the bug will not be triggered in that case
- investigate the cabal bug and identify an existing issue or create a new one, trying to fix it asap
//cc @maerwald
- return to use
Well i think once we have
ghcup compile hls -g master --ghc 8.10.7 -- --ghc-options='-dynamic'ghcup compile hls -g master --ghc 8.10.7 -- -enable-executable-dynamicghcup compile hls -g master --ghc 8.10.7 --cabal-project-local https://gist.githubusercontent.com/jneira/c0b0dc1297907a5a139c4ecf4eb6ccd3/raw/c97c97181182b15455cb3969abac2dc164d74b91/cabal-dynhls.project.localthe support for build hls dynamic executable is covered enough and we could close this one
Edited by Javier Neira
