#1798: add better framework support to ghc
------------------------------+---------------------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Unknown | Os: MacOS X
Testcase: | Architecture: Multiple
------------------------------+---------------------------------------------
ghc should be enabled to find a framework at runtime even in a user's home
directory.
Currently ghci cannot load a framework from a user's home directory. (ghci
may find a framework in a directory given under `frameworkDirs` in a
`package.conf`, though)
If ghc would find the path to a framework `Bla' (at runtime) it could
generate proper include and link options as follows.
Be `<fpath>` the path to the directory `Bla.framework` (containing
framework `Bla`) then
{{{
-I<fpath>/Bla.framework/Headers
}}}
should be added as include-path for header files.
{{{
-F<fpath> -framework Bla
}}}
are the linker flags and
{{{
<fpath>/Bla.framework/Bla
}}}
is the dynamic library to be loaded by `dlopen`.
Currently only "`-framework Bla`" is passed to linker and the dynamic
linker tries to find the framework under `/Library/Frameworks`,
`/System/Library/Frameworks` and directories (that must be known at build
time) under `frameworkDirs`.
Currently C-Header files are only found if they are included in source
files as:
{{{
#include <Bla/blaheader.h>
}}}
This is rather unportable (as it only works on Macs) and requires library
writers to create code (and configure stuff) like:
{{{
#if defined(HAVE_FRAMEWORK_GMP)
#include <GMP/gmp.h>
#else
#include <gmp.h>
#endif
}}}
(I'm not even sure if the recursive includes work for the GNUreadline
framework. see #1395)
if "`#include <Bla/blaheader.h>`" should work with frameworks installed
under `<fpath>` not being /Library/Frameworks or
/System/Library/Frameworks then also `-F<fpath>` needs to be passed to the
C-compiler. (But it is better to always only write "`#include
<blaheader.h>`" and use the above include flag.)
By accident the GNUreadline framework can be dynamically loaded from a
user's home directory because ghci itself loads this framework (provided
the `package.conf` file does not mention the framework GNUreadline, see
#1395)
All these disadvantages can be avoided by computing the `<fpath>` for
every framework at runtime.
(The code is almost there at the end of `compiler/ghci/Linker.lhs`)
Once this all works the next step would be to also add a proper include-
path to `hsc2hs` as it is currently rather difficult to pass
`-I$HOME/Library/Frameworks/GNUreadline.framework/Headers` to `hsc2hs`
when building `libraries/readline` with Cabal!
Christian
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1798>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
