Handle framework paths (-F) in Cabal

[bos]

(Imported from Trac #189, reported by guest on 2007-12-10)

There's been some discussion on the GHC trac (1931, 1798, 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 [OSXFrameworks](http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks) for more info.

-Judah

[bos]

(Imported comment by guest on 2007-12-10)

A better name for the field may be framework-dirs: (corresponding to the frameworkDirs field which is already present in ghc's package.conf).

[bos]

(Imported comment by guest on 2007-12-10)

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@…)

[bos]

(Imported comment by @dcoutts on 2008-01-04)

I don't know much about frameworks, could someone tell me:

1. How are framework paths supposed to be found generally?
2. Are their locations fixed or do their location vary from one machine to the next?
3. Are frameworks versioned?
4. 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.

[bos]

(Imported comment by guest on 2008-01-04)

Replying to @dcoutts:

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/Concepts/VersionInformation.html

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

[bos]

(Imported comment by @dcoutts on 2008-01-05)

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?

[bos]

(Imported comment by guest on 2008-01-07)

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@…)

[bos]

(Imported comment by guest on 2008-01-07)

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@…)

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

[bos]

(Imported comment by guest on 2008-01-07)

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

[bos]

(Imported comment by guest on 2008-01-07)

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)?

[bos]

(Imported comment by guest on 2008-01-21)

sign previous comment -- Christian M. (see CC)

P.S. the two trac spaces are confusing

[bos]

(Imported comment by guest on 2008-01-21)

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

[bos]

(Imported comment by @dcoutts on 2008-01-21)

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).

[bos]

(Imported comment by @dcoutts on 2008-01-22)

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.

[tibbe]

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

[mietek]

A concrete application for -framework-path would be using frameworks installed by brew, e.g. /usr/local/Cellar/r/3.1.0/R.framework.

[komadori]

It used to be possible to pass the -framework-path option in via the ghc-options field, but now that shared library builds are standard, the ghcSharedLinkArgs construction in Distribution.Simple.GHC doesn't permit any mechanism for sending custom options to the final link command. AFAICS, on MacOS 10.11, the only way to use a framework without being able to specify this flag is to place it inside the Xcode bundle. This makes it quite difficult to work with frameworks.

I have created a patch to add a framework-dirs field paralleling the existing include-dirs and extra-lib-dirs fields.