-
Notifications
You must be signed in to change notification settings - Fork 696
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
Improve online docs for includes:
field
#10145
Conversation
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
I don't understand. Cabal was written to be a specification. Whether GHC supports all the things is kind of irrelevant to the spec. The question is, does an |
@hasufell, I had a similar thought, but in connection with: rather than this change to the online documentation. (With the documentation, I did hesitate over adding 'deprecated' but lots of Haskell packages - including GHC boot packages - no longer use the redundant - from a GHC perspecive - The following comment may be better at #10147: I appreciate that the Cabal User Guide still states:
but is that true of Cabal (the library) in 2024? In practice, do the Cabal team actively consider the possibility of Haskell implementations other than GHC? |
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
I have removed |
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
I would be surprised if that were the case for three reasons:
But given haskell/network#582 (comment) I agree that it makes sense to track down what exactly is still done with |
#10153 demonstrates that there are no (undocumented) uses of The only things that Cabal does with |
I've added to my list of 'bases' above GHC's current documentation. |
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
I am going to restore the (a) I think it has now been copper-bottomed that GHC has not used Cabal's |
I think that's the key observation here.
In addition,
Given all this, I kind of hope that all of us at least agree that something has to be done here. While I don't have a strong opinion on how exactly to change the documentation, I do think that this PR is an improvement over the status quo. |
This is exactly what the cabal documentation suggests:
What other interpretation here is possible? Whether GHC did something sensible is an entirely different discussion and I find it rather irrelevant. This is a spec.
This is not obvious at all. Again, this is a spec, not a shim over Makefiles. It doesn't have to map 1:1 to how you interact with gcc.
Yes, I'd like to understand what was the original motivation as opposed to how it was actually used. |
I think "exactly" is a little bit strong here, but I agree that the Cabal documentation is potentially misleading. This is how I originally interpreted it:
However, it turns out, that Unless proven otherwise, I assume |
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
I've merged haskell/win32#233 because that seems to be the direction things went, however I wanted to point out that:
This in itself was useful. The reason at least win32 had these was because of it's extensive use of hsc2hs. Cabal checking the existence of the header files provided a better user experience than So these changes will potentially make it much harder to figure out compile errors later. Also note that To me the difference between
I 100% agree with this comment. I hope whatever discussion is had does not focus on what GHC does. This information is there and useful for custom build types as it's available through the Hook structures.
So please don't focus Cabal solely on what GHC does or uses. |
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
This is useless at best, and a common source of confusion. haskell/cabal#10145 sol/hpack#355
Bases for additions to online docs:
https://downloads.haskell.org/~ghc/6.10.1/docs/html/users_guide/release-6-10-1.html ("... the
includes
field in.cabal
files ... all have no effect when compiling Haskell source code.")EDIT: https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/ffi.html#using-header-files ("... the
include-files
field in a Cabal package specification is ignored.") (The reference toinclude-files
is as in the original; it can be understood to meanincludes
.) EDIT2: https://gitlab.haskell.org/ghc/ghc/-/issues/25032https://hackage.haskell.org/package/Cabal-2.0.0.2/changelog ("Dropped support for versions of GHC earlier than 6.12 ...")
e1c39fc (removes use of GHC's
-#include
option)Patches conform to the coding conventions. N/A
Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions). N/A