Re: ghci finding include files exported from other packages?
On Tue, 2009-03-17 at 08:53 +, Simon Marlow wrote: > Duncan Coutts wrote: > > On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: > > > > Yes, if we know we're using it. If we specify -package blah on the > > command line then we do know we're using it and everything works > > (because ghc uses the include-dirs when it calls cpp). If we don't > > specify -package then ghc does not know we need the package until after > > import chasing is done. Import chasing requires that we run cpp on > > the .hs file first and that brings us full circle. > > I don't see a reason why we shouldn't pass *all* the include paths for the > exposed packages to CPP. Indeed that's what I thought we did, but I've > just checked and I see we don't. Wouldn't that fix Conal's problem? Yes it probably would. On my system that'd only be between 25-50 include directories, which I guess is not too bad. Lets hope not too many packages decide they need a "config.h" file. So, presumably by passing all include dirs for all exposed packages that takes into account -package flags, so when Cabal does -hide-all-packages then it gets its desired behaviour. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
Duncan Coutts wrote: On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: This sounds like a chicken and egg problem. To know which package include directories to use GHCi needs to know which packages your module uses. However to work out which packages it needs it has to load the module which means pre-processing it! With cabal we get round this problem because Cabal calls ghc with -package this -package that etc and so when ghc cpp's the module it does know which package include directories to look in. Perhaps I'm missing something, but if applicative-numbers is an exposed package, shouldn't we be adding its include-dirs when invoking CPP? Yes, if we know we're using it. If we specify -package blah on the command line then we do know we're using it and everything works (because ghc uses the include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle. I don't see a reason why we shouldn't pass *all* the include paths for the exposed packages to CPP. Indeed that's what I thought we did, but I've just checked and I see we don't. Wouldn't that fix Conal's problem? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
On Mon, 2009-03-16 at 16:04 -0700, Conal Elliott wrote: > On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts > wrote: > On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: > > Perhaps I'm missing something, but if applicative-numbers is > an exposed > > package, shouldn't we be adding its include-dirs when > invoking CPP? > > > Yes, if we know we're using it. If we specify -package blah on > the > command line then we do know we're using it and everything > works > (because ghc uses the include-dirs when it calls cpp). If we > don't > specify -package then ghc does not know we need the package > until after > import chasing is done. Import chasing requires that we run > cpp on > the .hs file first and that brings us full circle. > > Duncan > > Unless you drop the cpp-first requirement and have import-chasing look > into #include'd files, as I described earlier. - Conal Yes, that's what I said earlier about re-implementing cpp, possibly via cpphs. That would let you chase #includes and assuming you know which packages provide which include files then we could work out which packages are needed for cpp-ing. Or you could play it fast and loose and assume that you can usually ignore # cpp lines and still work out what the Haskell imports are most of the time. That's not correct but is probably easier and would probably work most of the time. Neither approach is easy or very nice. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts wrote: > On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: > > > > This sounds like a chicken and egg problem. To know which package > > > include directories to use GHCi needs to know which packages your > module > > > uses. However to work out which packages it needs it has to load the > > > module which means pre-processing it! > > > > > > With cabal we get round this problem because Cabal calls ghc with > > > -package this -package that etc and so when ghc cpp's the module it > does > > > know which package include directories to look in. > > > > Perhaps I'm missing something, but if applicative-numbers is an exposed > > package, shouldn't we be adding its include-dirs when invoking CPP? > > Yes, if we know we're using it. If we specify -package blah on the > command line then we do know we're using it and everything works > (because ghc uses the include-dirs when it calls cpp). If we don't > specify -package then ghc does not know we need the package until after > import chasing is done. Import chasing requires that we run cpp on > the .hs file first and that brings us full circle. > > Duncan Unless you drop the cpp-first requirement and have import-chasing look into #include'd files, as I described earlier. - Conal ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: > > This sounds like a chicken and egg problem. To know which package > > include directories to use GHCi needs to know which packages your module > > uses. However to work out which packages it needs it has to load the > > module which means pre-processing it! > > > > With cabal we get round this problem because Cabal calls ghc with > > -package this -package that etc and so when ghc cpp's the module it does > > know which package include directories to look in. > > Perhaps I'm missing something, but if applicative-numbers is an exposed > package, shouldn't we be adding its include-dirs when invoking CPP? Yes, if we know we're using it. If we specify -package blah on the command line then we do know we're using it and everything works (because ghc uses the include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
Duncan Coutts wrote:
On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote:
The applicative-numbers package [1] provides an include file. With
ghci, the include file isn't being found, though with cabal+ghc it is
found.
My test source is just two lines:
{-# LANGUAGE CPP #-}
#include "ApplicativeNumeric-inc.hs"
I'd sure appreciate it if someone could take a look at the .cabal file
[2] and tell me if I'm doing something wrong. And/or point me to one
or more working examples of cabal packages that export include files
that are then findable via ghci.
This sounds like a chicken and egg problem. To know which package
include directories to use GHCi needs to know which packages your module
uses. However to work out which packages it needs it has to load the
module which means pre-processing it!
With cabal we get round this problem because Cabal calls ghc with
-package this -package that etc and so when ghc cpp's the module it does
know which package include directories to look in.
Perhaps I'm missing something, but if applicative-numbers is an exposed
package, shouldn't we be adding its include-dirs when invoking CPP?
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
Thanks for the clarification, Duncan. Seems an easy partial solution would be a single pass (before CPP) that notices just the #include directives. Consult the package database to find those packages. That route would find direct includes but not indirect ones. An optional and still-easy next step would be to look inside those includes for further #include directives. I'm unsure whether the cabal solution is as powerful as the single-level include method or the recursive one. - Conal On Sun, Mar 15, 2009 at 2:34 PM, Duncan Coutts wrote: > On Sun, 2009-03-15 at 09:13 -0700, Conal Elliott wrote: > > That did it. I've added ":set -package applicative-numbers" to > > my .ghci and am back in business. Thanks! > > > > IIUC, there's an inconsistency in ghci's treatment of modules vs > > include files, in that modules will be found without -package, but > > include files won't. Room for improvement, perhaps. > > But that's because of the circularity I described. GHC can chase Haskell > imports because it can parse Haskell, but chasing CPP #includes would > require us to re-implement cpp. Perhaps we could do it by modifying > cpphs. > > Duncan > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
On Sun, 2009-03-15 at 09:13 -0700, Conal Elliott wrote: > That did it. I've added ":set -package applicative-numbers" to > my .ghci and am back in business. Thanks! > > IIUC, there's an inconsistency in ghci's treatment of modules vs > include files, in that modules will be found without -package, but > include files won't. Room for improvement, perhaps. But that's because of the circularity I described. GHC can chase Haskell imports because it can parse Haskell, but chasing CPP #includes would require us to re-implement cpp. Perhaps we could do it by modifying cpphs. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
That did it. I've added ":set -package applicative-numbers" to my .ghci and
am back in business. Thanks!
IIUC, there's an inconsistency in ghci's treatment of modules vs include
files, in that modules will be found without -package, but include files
won't. Room for improvement, perhaps.
- Conal
On Sun, Mar 15, 2009 at 5:27 AM, Duncan Coutts
wrote:
> On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote:
> > The applicative-numbers package [1] provides an include file. With
> > ghci, the include file isn't being found, though with cabal+ghc it is
> > found.
> >
> > My test source is just two lines:
> >
> > {-# LANGUAGE CPP #-}
> > #include "ApplicativeNumeric-inc.hs"
> >
> > I'd sure appreciate it if someone could take a look at the .cabal file
> > [2] and tell me if I'm doing something wrong. And/or point me to one
> > or more working examples of cabal packages that export include files
> > that are then findable via ghci.
>
> This sounds like a chicken and egg problem. To know which package
> include directories to use GHCi needs to know which packages your module
> uses. However to work out which packages it needs it has to load the
> module which means pre-processing it!
>
> With cabal we get round this problem because Cabal calls ghc with
> -package this -package that etc and so when ghc cpp's the module it does
> know which package include directories to look in.
>
> So if you did ghci -package applicative-numbers then it should work. I'm
> afraid I don't have any good suggestion for how to make it work with
> ghci without having to specify any options at all.
>
> Duncan
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote:
> The applicative-numbers package [1] provides an include file. With
> ghci, the include file isn't being found, though with cabal+ghc it is
> found.
>
> My test source is just two lines:
>
> {-# LANGUAGE CPP #-}
> #include "ApplicativeNumeric-inc.hs"
>
> I'd sure appreciate it if someone could take a look at the .cabal file
> [2] and tell me if I'm doing something wrong. And/or point me to one
> or more working examples of cabal packages that export include files
> that are then findable via ghci.
This sounds like a chicken and egg problem. To know which package
include directories to use GHCi needs to know which packages your module
uses. However to work out which packages it needs it has to load the
module which means pre-processing it!
With cabal we get round this problem because Cabal calls ghc with
-package this -package that etc and so when ghc cpp's the module it does
know which package include directories to look in.
So if you did ghci -package applicative-numbers then it should work. I'm
afraid I don't have any good suggestion for how to make it work with
ghci without having to specify any options at all.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci finding include files exported from other packages?
The applicative-numbers package [1] provides an include file. With ghci,
the include file isn't being found, though with cabal+ghc it is found.
My test source is just two lines:
{-# LANGUAGE CPP #-}
#include "ApplicativeNumeric-inc.hs"
I'd sure appreciate it if someone could take a look at the .cabal file [2]
and tell me if I'm doing something wrong. And/or point me to one or more
working examples of cabal packages that export include files that are then
findable via ghci.
- Conal
[1] http://hackage.haskell.org/packages/archive/applicative-numbers
[2]
http://hackage.haskell.org/packages/archive/applicative-numbers/0.0.2/applicative-numbers.cabal
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
