Should `includes:` field be removed from the specification?

mpilgrem commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

haskell / cabal

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