I am afraid it is not… This is mea culpa. I completed the vast majority of the work for this migration and fell behind with various non-OSS obligations these last few weeks.
It’s a real shame and I’m kicking myself, because it actually compiles and mostly works, but I didn’t spend the time fixing the test suite…
Sorry I’ll try to find some time over Christmas…
I haven’t merged it yet, because it turns out there is an unadvertized bindist (Fedora 27) that could fix a lot of the glibcissues.
So we’re evaluating whether to change the existing GHC bindist mapping and whether to rebuild HLS binaries.
Release coordination is complicated here. GHCup depends on GHC to provide binaries, HLS depends on GHCup to build binaries and then GHCup depends on HLS to provide binaries. If we get something minor wrong like using a too new glibc as a catch-all fallback for unknown linux distros, then it’s large breakage.
We’ve been trying to improve communication and coordination here. It has improved, but is still not enough.
Please bear with us.
(Also: I think we shouldn’t do releases during Christmas time)
first thank you very much for your great work there (and of course to the team).
It’s probably some combination on my machine but I’m experiencing problems with the 1.9.0.0 binary (the 1.8.0.0 locally compiled for 9.2.5 works great).
I’m still trying to figure out what exactly fails/makes problems here but when I open a project/folder with VS code that is a symbolic link to another folder the plugin seems to get confused (you see multi-cradle errors where the actual and linked folders are mentioned) - also there seems to be some kind of loop where I see “project 2/60” over and over again in the status-bar of vs code.
Finally HLS seems to work but when I “goto source” via F12 it does not in this file (when I navigate to the file via Files in VS code it works.)
I’m trying to find a minimal repro of this issue and might file an issue but for now I’ll stick with 1.8.0.0