You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:?
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.
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 copiedWin32
(for example,mintty
andansi-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:
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 ofhs-source-dirs
) 2.0, removed 3.0extensions
: deprecated (in favour ofdefault-extensions
) 1.12, removed 3.0build-tools
: deprecated (in favour ofbuild-tool-depends
) 2.0, removed 3.0EDIT3: GHC's
CApiFFI
language extension was introduced in GHC 7.6.1 (that is, after GHC had begun to ignore Cabal'sincludes:
field). I have not identified anything in the documentation to suggest that GHC began to pay attention again to the field on its introduction.The text was updated successfully, but these errors were encountered: