search

shayne-fletcher / ghc-lib-parser-ex

GHC API parse tree utilities
Other
10 stars 4 forks source link

Error when compiling with GHC 8.6.5 Windows #38

Closed ndmitchell closed 4 years ago

ndmitchell commented 4 years ago 
cbits\ghclib_api.h:28:10: error:
     error: #error Unsupported GHC API version
     #        error Unsupported GHC API version
              ^~~~~
   |
28 | #        error Unsupported GHC API version
   |          ^
`gcc.exe' failed in phase `C pre-processor'. (Exit code: 1)
ndmitchell commented 4 years ago

I was compiling the very latest 8.10 version.

shayne-fletcher commented 4 years ago

With this section enabled?

flags:
  hlint:
    ghc-lib: true
  ghc-lib-parser-ex:
    ghc-lib: true
shayne-fletcher commented 4 years ago

Be sure to pass the cabal flags -f hlint:ghc-lib -f ghc-lib-parser-ex:ghc-lib

ndmitchell commented 4 years ago

Would be much better if it just worked out the box on 8.6.5, since there's no chance of anyone manually setting flags.

shayne-fletcher commented 4 years ago

I understand. Maybe the way forward is if ghc-lib-parser-ex were to default to linking ghc-lib-parser unless told explicitly to link native-libs? Then,

  -- Unless explicitly told to link ghc-lib-parser, assume ghc native.
  if !flag(ghc-lib)
      build-depends:
        ghc,
        ghc-boot-th,
        ghc-boot
  else
      build-depends:
        ghc-lib-parser

would become,

  -- Unless explicitly told to NOT link ghc-lib-parser, assume ghc native.
  if !flag(no-ghc-lib)
      build-depends:
        ghc,
        ghc-boot-th,
        ghc-boot
  else
      build-depends:
        ghc-lib-parser

That might be the better behavior?

ndmitchell commented 4 years ago

I would have thought ghc-lib-parser-ex-8.10 would link against ghc-8.10 when you are on 8.10, and when you aren't, use ghc-lib-parser, but have a flag to always link against ghc-lib-parser. That way you default to the right behaviour, and have a single flag to opt into using ghc-lib-parser even though you don't have to.

HLint probably needs to mirror those flags and defaults.

shayne-fletcher commented 4 years ago

would have thought ghc-lib-parser-ex-8.10 would link against ghc-8.10 when you are on 8.10

How do you express that in the cabal file? Remember, ghc-lib-parser-ex supports all of 8.8, 8.10 and 8.11?

ndmitchell commented 4 years ago

Hmm. That makes it harder. I don't know... The end goal I think would be ideal is if HLint on GHC 8.10 didn't have to compile ghc-lib-parser (so it builds faster), but everywhere else it did (so I only have to support one interface). I also think that the ability to reuse the GHC package will be important for people who want to link against it using the GHC types directly. Not sure how you solve that - perhaps have ghc-lib-parser-ex default to 8.10, but have manual flags to make it always pick GHC (which would fail on 8.6) and always pick ghc-lib-parser (which always works).

shayne-fletcher commented 4 years ago

How about something like this?

flag auto
  default: True
  manual: True

flag no-ghc-lib
  default: False
  manual: True

if flag(auto) && impl(ghc >= 8.10.0) && impl(ghc < 8.11.0)
  build-depends:
    ghc == 8.10.*,
    ghc-boot-th,
    ghc-boot
else
  if flag(auto)
    build-depends:
      ghc-lib-parser == 8.10.*
  else
    if flag(no-ghc-lib)
      build-depends:
        ghc,
        ghc-boot-th,
        ghc-boot
    else
      build-depends:
        ghc-lib-parser
shayne-fletcher commented 4 years ago

Another idea. How about something like this?

The above idea is implemented in https://github.com/shayne-fletcher/ghc-lib-parser-ex/pull/42

shayne-fletcher commented 4 years ago

The above scheme has the property that it works out of the box for hlint with no flags for all supported ghc lib versions including choosing ghc libs on 8.10 and ghc-lib-parser-8.10 otherwise.

shayne-fletcher commented 4 years ago

That change landed.