yaxu / feedforward

GNU General Public License v3.0
129 stars 10 forks source link

Build issues on Manjaro #36

Open Dsm0 opened 2 years ago

Dsm0 commented 2 years ago

TLDR: getting

 > /tmp/stack-0ac71fc0d961d4f6/ncurses-0.2.16/.st
ack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0/build/UI/NCurses.chs
.h:10:10: fatal error: ncursesw/ncurses.h: No such file or directory
ncurses             >    10 | #include <ncursesw/ncurses.h>
ncurses             >       |          ^~~~~~~~~~~~~~~~~~~~
ncurses             > compilation terminated.
ncurses             > c2hs: Error during preprocessing custom header

error on manjaro because ncurses has a different path name on arch-linux.

On a fresh clone of the repo, I get a version error:

`In the dependencies for feedforward-0.0.1:
    tidal-0.9.9 from stack configuration does not match >=1.7.2  (latest matching version is 1.7.8)
needed since feedforward is a build target.

Some different approaches to resolving this:

  * Set 'allow-newer: true' in /home/will/.stack/config.yaml to ignore all version constraints and build anyway.

  * Recommended action: try adding the following to your extra-deps in /home/will/gitshit/feedforward/stack.yaml:

- tidal-1.7.8@sha256:a17fe71112f97b412457a0ed8c2d9bd93fe4bcabe62c30493320191557b005ee,4017

Plan construction failed.`

If tidal-1.7.8 is added to extra-deps, it then asks for

- hosc-0.19.1@sha256:e969ae92fdc7a53c4e958ea35acc097317635522684b1f68705ceda34af43461,2017

If that gets added, I get


--  While building package ncurses-0.2.16 (scroll up to its section
to see the error) using:
      /home/will/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-si
mple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-l
inux-tinfo6/Cabal-2.0.1.0 build --ghc-options " -fdiagnostics-color=
always"
    Process exited with code: ExitFailure 1

which seems to be the core issue.

It seems that [others have encountered this path issue as well](others have encountered it as well).

I'm sure I could hack something together that gets it to build, but I bet there's a better way to fix the issue. Any ideas?

Dsm0 commented 2 years ago

Update: I fixed the #include <ncursesw/ncurses.h> error by installing ncurses5-compat-libs, but another issue persists.

Here's the output for stack build:

ncurses    > configure
ncurses    > Configuring ncurses-0.2.16...
ncurses    > build
ncurses    > Preprocessing library for ncurses-0.2.16..
ncurses    > c2hs: C header contains errors:
ncurses    >
ncurses    > .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0/build/UI/NCurses.i:1: (colu
mn 1) [ERROR]  >>> Lexical error !
ncurses    >   The character '#' does not fit here.
ncurses    >
Progress 1/2

--  While building package ncurses-0.2.16 (scroll up to its section to see the error) using
:
      /home/will/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_2.0.1.0_g
hc-8.2.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0 build --ghc-options
" -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

A discussion I found alleges the problem is that the library c2hs uses to preprocess doesn't support some newer language features. It looks like all this stems from the use of haskell's ncurses lib, which was last updated in 2017.

I'm wondering if it might be easier in the long run to switch to a different ncurses library. I'll continue investigating this issue and the feasibility of changing ncurses libs.

yaxu commented 2 years ago

Thanks for looking into this!

Dsm0 commented 2 years ago

quick update: looked into it a bit. The best, actively maintained tui library is brick. But brick runs on top of vty, which (to my knowledge) currently [doesn't have windows compatibility](doesn't have windows compatibility). It seems a bit silly to transfer to another library and gut most (if not all) of the editor code just to support arch instead of windows. I feel like something should be done to ensure consistent linux compatibility, but I'm not sure what. I'll look into the ncurses library itself and see if there's a fix. This seems like a simpler short-term fix, as the library is relatively small.