[Hackage] #189: Handle framework paths (-F) in Cabal
#189: Handle framework paths (-F) in Cabal --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Mac OS | --------------------------+------------------------------------------------- There's been some discussion on the GHC trac ([http://hackage.haskell.org/trac/ghc/ticket/1931 1931], [http://hackage.haskell.org/trac/ghc/ticket/1798 1798], [http://hackage.haskell.org/trac/ghc/ticket/1395 1395]) about adding framework search paths (gcc's `-F` flag, and ghc's `-framework-path` flag). Currently Cabal handles `-framework`, but not `-framework-path`. I propose the following behavior for Cabal: 1. Add a `framework-path:` field which will pass `-framework-path` to `ghc` and `-F` to `gcc`, `hsc2hs`, et. al. 2. Always add `-F$HOME/Library/Frameworks` as an argument to the above programs (regardless of any `framework-path` entries). I believe `#1` to be uncontroversial. My reasoning for `#2` is the following: - `$HOME/Library/Frameworks` is the standard location to put frameworks if you do not have administrative access. - Without it, `readline.cabal` (e.g.) would need {{{ framework-path: /Users/judah/Library/Frameworks }}} which is not portable between machines. Finally, note that these flags only affect build behavior, not runtime loading of libraries (which searches `$HOME/Library/Frameworks` by default). See [http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks OSXFrameworks] for more info. -Judah -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.1 | Platform: Mac OS --------------------------+------------------------------------------------- Comment (by guest): A better name for the field may be `framework-dirs:` (corresponding to the `frameworkDirs` field which is already present in ghc's `package.conf`). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Changes (by guest): * ghcversion: 6.8.1 => 6.8.2 Comment: cabal should not need to pass `$HOME/Library/Frameworks` to ghc. ghc itself should pass `-F$HOME/Library/Frameworks` to gcc and the linker on Macs. See my (most recent) file `DriverPipeline.hs` in http://hackage.haskell.org/trac/ghc/ticket/1395 Christian (.Maeder@dfki.de) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): I don't know much about frameworks, could someone tell me: 1. How are framework paths supposed to be found generally? 1. Are their locations fixed or do their location vary from one machine to the next? 1. Are frameworks versioned? 1. Can we find frameworks at configure time rather than failing at link time? If framework paths vary from one machine to another then putting "framework-dirs:" in the .cabal file would not make a lot of sense. If they cannot be found automatically and require extra information from the user then perhaps it should be a configure option. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): Replying to [comment:3 duncan]:
I don't know much about frameworks, could someone tell me:
Briefly: A framework is a directory ending in `.framework` which stores the header and object files associated with a library. Saying `"-framework GNUreadline"` is like saying `"-lreadline"`. Saying `"-F$HOME/Library/Frameworks"` is like saying `"-I$HOME/includes -L$HOME/lib"` .
1. How are framework paths supposed to be found generally? 1. Are their locations fixed or do their location vary from one machine to the next?
The frameworks themselves are found automatically by `gcc` and `ld`, as long as they're stored in either `/System/Library/Frameworks` (for Apple's use only) or `/Library/Frameworks` (for user-installed frameworks). Sometimes they are stored in other standard locations: - $HOME/Library/Frameworks (if you don't have administrator access) - /Network/Library/Frameworks (if the framework should be shared by several users on a network) The problem is that the compiler and linker don't search those folders by default (although the runtime dynamic loader does). So calling `gcc` with `-F$HOME/Library/Frameworks` tells it to search that folder for any required frameworks. Another reason to use a nonstandard location is testing a build against a new version of a framework.
1. Are frameworks versioned? Yes, and you can distribute one framework which contains multiple versions. The technical details are at http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Conc...
1. Can we find frameworks at configure time rather than failing at link time? If framework paths vary from one machine to another then putting "framework-dirs:" in the .cabal file would not make a lot of sense. If they cannot be found automatically and require extra information from the user then perhaps it should be a configure option.
As I said above, the `-F` flag is the equivalent of the `-I` and `-L` flags. So I think that `framework-dirs` should be in the `cabal` file just like `include-dirs` and `extra-lib-dirs` are. -Judah -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): Correct me if I'm wrong... So we already have a frameworks field in the .cabal file. So we know which frameworks we need. gcc/ghc knows where to find these frameworks at compile and link time if they are installed in the standard place (now that ghc tells gcc to look in $HOME/Library/Frameworks). So is the only problem that we cannot find frameworks if they are installed in non-standard locations? If so then I do not see that adding a framework-paths field to the .cabal file will help since if it's a non- standard path then it varies from one machine to another so putting it in the .cabal file is pointless. If we really have a need to find framworks in non-standard places then perhaps a configure flag is in order. The point about include-dirs and extra-lib-dirs is that they are for dirs that are standard locations across machines, eg /usr/include/mysql. Or if they have to be found on each machine then the values can be filled in using custom code in Setup.hs or a ./configure script. This might be useful to frameworks too if there is some way of finding them automatically. Am I still not understanding the problem? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): So far, I've seen no application of the -framework-path of ghc (except maybe to pass `$HOME/Library/Frameworks`) and also no use of the package.conf entry `frameworkDirs` (I think, it may be nuked.) Frameworks are usually in standard places. Christian (.Maeder@dfki.de) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
So far, I've seen no application of the -framework-path of ghc (except maybe to pass `$HOME/Library/Frameworks`) and also no use of the
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): package.conf entry `frameworkDirs` (I think, it may be nuked.) Frameworks are usually in standard places.
Christian (.Maeder@dfki.de)
When I was testing problems with `GNUreadline.framework`, I often wanted a way to link against a second version of the framework in a nonstandard location. For example, if I was booting ghc-6.9 with ghc-6.2, I wanted ghc-6.2 to use the old version of `GNUreadline.framework` but ghc-6.9 to use the new version. So I definitely think it's useful. But I would be happy with Duncan's suggestion to make it a configure flag instead of a .cabal file field, as long as: 1. Cabal provides that functionality automatically (without me having to manually edit an autoconf script) 2. The results of that flag end up in ghc's `package.conf` `frameworkDirs` field. -Judah -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): There's another use for -framework-path that I just thought of: Apple provides old versions of the system frameworks, e.g. on my 10.4 machine I have `/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/` which is not searched by default. -Judah -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): We have a problem with hsc2hs, because hsc2hs can be called with gcc and ghc as C-compilers. gcc expects a -F option whereas ghc -framework-path. One alternative would be to make hsc2hs smarter, but maybe ghc could be made to change its -F interpretation. Can cabal always pass proper options to hsc2hs (and hsc2hs blindly passes them on)? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Changes (by guest): * cc: Christian.Maeder@dfki.de (added) Comment: sign previous comment -- Christian M. (see CC) P.S. the two trac spaces are confusing -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:10 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): Yes, Cabal already has code which passes different options to hsc2hs depending on whether it's using ghc or gcc. In particular, see the source code for the function `Distribution.Simple.PreProcess.ppHsc2hs` . -Judah -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:11 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): The proper solution of course is for hsc2hs to only ever use gcc and not ghc. It is insanity that the caller needs to know so that we can pass the right flags. To add to the insanity, there's no sensible way of finding out if it's using ghc or gcc (Cabal does find out by using a cunning hack). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:12 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Changes (by duncan): * milestone: => _|_ Comment: The issue with `hsc2hs` is fixed. What we need now is a clear description of the remaining problem and some suggestions for a solution. We'll also need some people on OSX who can verify that anything we implement actually does what it is supposed to. Volunteers please. Assigning to milestone _|_ because we need more info before we can proceed. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/189#comment:13 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage