Foreign Library Stanza

[ropwareJB]

• [Y ] Did you add a new feature to hpack?
  • [Y] Did you add an acceptance test for that new feature to test/EndToEndSpec.hs?

Addresses #258.

Adds the following syntax to support foreign / shared libraries so we dont need to use the verbatim block anymore:

foreign-library:
  type: native-shared
  source-dirs: driver
  options:
    - standalone
  dependencies:
    - hpack

[mpilgrem]

I do not know why the CI is failing for Windows/'system' GHC (being GHC 9.6.2). I logged https://gitlab.haskell.org/ghc/ghc/-/issues/23533 as it seems to be GHC-related.

Locally, I can build and test (stack test) the Hpack respository at commit 36c44de with Stack configuration:

resolver: nightly-2023-06-18 # GHC 9.4.5
compiler: ghc-9.6.2

extra-deps:
# GHC 9.6.2 boot libaries
- Cabal-3.10.1.0
- Cabal-syntax-3.10.1.0
- directory-1.3.8.1
- time-1.12.2
- process-1.6.17.0
- Win32-2.13.3.0
# Required because the Stackage snapshot versions do not support GHC 9.6.2
- semigroupoids-6.0.0.1
- bifunctors-5.6.1

[sol]

Thanks @mpilgrem.

[mpilgrem]

I have rebased on the main branch and squashed the existing commits making up the pull request.

[mpilgrem]

@sol, I think this is good to merge. Do you want to review?

[sol]

@sol, I think this is good to merge. Do you want to review?

@mpilgrem Hold back first, I'm gonna look at it sometime soon.

[sol]

@mpilgrem I rebased again. But commits don't seem to be squashed yet.

[mpilgrem]

@sol, I've squashed but I was not sure if your review was complete subject to that?

[sol]

First, despite what I was saying earlier, I want to raise the questions "Do we really want this?" and "Is this within the scope of Hpack?"

For Linux I don't know, I think you usually would go the other way around and use foreign imports. Are there any plausible use cases? If it is just for experimentation, then it would probably be outside the scope of Hpack.

For Windows however, the GHC documentation provides a VBA example. So if people wanna move business logic from Excel to Haskell then I can sympathize with that.

Maybe that's enough as a justification?

EDIT: I think this can actually be useful in combination with Python and ctypes, so let's go for it.

Regarding the implementation, I think type is a no-brainer, just remove it.

options on the other hand is more complicated. From what I understand, if we drop options then you would unconditionally need to generate

if os(Windows)
  options: standalone

While this is in line with "Don't require the user to state the obvious" I'm still puzzled how we would achieve "Give the user 100% control when needed" here? I think a user will not be able to override this with verbatim. But maybe just drop it anyway and address the 100% control thing once somebody asks for it?

BTW: I kind of think that if we decide to include this feature then we should probably include a complete example in the README, similar to what the GHC documentation contains, so that a user does not need to traverse three different manuals to make sense of this. EDIT: Even simple examples are still more complicated than I would hope for, so I'm not gonna insist on this just yet.

[sol]

Not related to this pull request, but I think this code does not handle internal libraries correctly. I think we need a separate issue or PR for that.

[mpilgrem]

Unrelated to this pull request.

[sol]

Same here, internal libraries are not handled here. If internal libraries cannot depend on the main library, then we are actually good. I'm not sure what's the situation here.

I think currently nobody is using this code, so maybe not a big issue. We could potentially deprecate it.

[mpilgrem]

Unrelated to this pull request.

[sol]

@mpilgrem I'm probably busy tomorrow, but gonna try to look at it again on Monday.

[mpilgrem]

@ropwareJB, @sol, I'm going to pay this PR some attention. I'll start by rebasing on main.

[mpilgrem]

@ropwareJB, @sol, I have a couple of questions:

On Linux only, Cabal supports a lib-version-linux field (API version) and a lib-version-info field (a GNU Libtool current[:revision[:age]] triple).

The former takes precedence over the latter, if both are specified:

• https://hackage-content.haskell.org/package/Cabal-syntax-3.16.1.0/docs/Distribution-Types-ForeignLib.html#v:foreignLibVersion

Q1. The original pull request assumes that Hpack will implement lib-version-info only. Is that the intention?

Q2. With this pull request, Hpack itself does not check that the supplied lib-version-info string is a valid Libtool triple. Is that how Hpack should behave?