
Hello Jeff, I'm not so shure if I understand what you mean (and I'm off for vacations in a few minute). So lets find out later. But you may try to set the --user to your config flags in menu: Packages/Edit Flags. Jürgen Jeff Heard wrote:
Jurgen... I have one more question, or rather request... I'm running under Ubuntu, and I get inconsistencies with packages that I build and install via Leksah not showing up when I configure other packages that depend on them. Then I notice that you're using runhaskell Setup.lhs ... to configure build and install. I wonder if you could change all that from "runhaskell Setup.lhs" to "cabal" wherever you run it? That would make things a lot more consistent overall, and probably jive better with the way most people install packages.
-- Jeff
On Thu, Apr 2, 2009 at 8:27 AM, jutaro
wrote: Hi Simon, you quite nicely describe what leksah is doing already. Try to find find the source code for all installed packages by locating cabal files, parse the module sources via the Ghc API (actually not so much the API), using info from cabal files for this (which is a dark art). It extracts comments and locations. It's quite an ad hoc solution. On my machine it's 97% successful, but its a notorious support theme, because it depends so much on the environment. Jürgen
Simon Marlow-7 wrote:
David Waern wrote:
2009/4/2 Duncan Coutts
: On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:
2009/4/1 jutaro
: > I guess you mean the dialog which should help leksah to find sources > for installed packages. It needs this so you can go to all the > definitions > in the base packages ... This is very handy if it works. Look to the > manual > for details. Maybe could add support to Cabal for installing sources? Should be very useful to have in general. http://hackage.haskell.org/trac/hackage/ticket/364 Jutaru, perhaps a nice Hackathon project? :-)
I think there's some design work to do there. See the discussion on the GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2630.
In short: just keeping the source code around isn't enough. You need some metadata in order to make sense of the source code - for example, you can't feed the source code to the GHC API without knowing which additional flags need to be passed, and those come from the .cabal file. Also you probably want to stash the results of the 'cabal configure' step so that you can get a view of the source code that is consistent with the version(s?) you compiled. We need to think about about backwards and forwards-compatibility of whatever metadata format is used.
And then you'll need Cabal APIs to extract the metadata. So we need to think about what APIs make sense, and the best way to do that is to think about what tool(s) you want to write and use that to drive the API design.
Perhaps all this is going a bit too far. Maybe we want to just stash the source code and accept that there are some things that you just can't do with it. However, I imagine that pretty soon people will want to feed the source code into the GHC API, and at that point we have to tackle the build metadata issues.
Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp2281603... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.