Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should includes: field be removed from the specification? #10147

Open
mpilgrem opened this issue Jun 24, 2024 · 4 comments
Open

Should includes: field be removed from the specification? #10147

mpilgrem opened this issue Jun 24, 2024 · 4 comments

Comments

@mpilgrem
Copy link
Collaborator

mpilgrem commented Jun 24, 2024

GHC has ignored it since GHC 6.10.1 (November 2008) and Cabal has not supported GHC versions before GHC 6.12 since Cabal-2.0.0.2 (July 2017). Given the passage of time, perhaps the field should be dropped from the Cabal Package Description Format Specification?

Be aware that Win32 still uses it (even though it has no effect) and other packages use it because they have simply copied Win32 (for example, mintty and ansi-terminal).

EDIT1: Elsewhere, @hasufell has identified that the discussion above is GHC-centric. In that regard, it is true that the Cabal User Guide still states:

One of the purposes of Cabal is to make it easier to build packages on different platforms (operating systems and CPU architectures), with different compiler versions and indeed even with different Haskell implementations. (Yes, there are Haskell implementations other than GHC!)

EDIT2: There are other examples where parts of the Cabal Package Description Format Specification have been deprecated and/or removed as things have developed:

  • hs-source-dir: deprecated (in favour of hs-source-dirs) 2.0, removed 3.0
  • extensions: deprecated (in favour of default-extensions) 1.12, removed 3.0
  • build-tools: deprecated (in favour of build-tool-depends) 2.0, removed 3.0

EDIT3: GHC's CApiFFI language extension was introduced in GHC 7.6.1 (that is, after GHC had begun to ignore Cabal's includes: field). I have not identified anything in the documentation to suggest that GHC began to pay attention again to the field on its introduction.

@mouse07410
Copy link
Collaborator

Since it's obvious how any why includes: should be used - if it's now deprecated or ignored, what field/keyword subsumed the functionality of includes:?

I can't believe it's just got ignored and dumped?

@geekosaur
Copy link
Collaborator

The problem is that it's applied to FFI calls, which used to go via C. These days they're done directly in assembly code, because ghc compiles to assembly code instead of C, so there's nowhere to put and no way to use C includes. That was why I asked about CApiFFI, which again does (only) FFI using the capi calling convention via C.

@geekosaur
Copy link
Collaborator

You'll have to ask in #ghc in libera or #GHC:matrix.org whether CApiFFI uses the functionality of includes:; ghc's documentation doesn't say.

@andreabedini
Copy link
Collaborator

Just to state the obvious. It might be deprecated but not be entirely removed. We have to be albe to read old cabal files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants