Handle framework paths (-F) in Cabal

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

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)

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.

Replying to 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/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

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?

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)

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)

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

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

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

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

P.S. the two trac spaces are confusing

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

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