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 <[email protected]> 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 <[email protected]>: >>>> On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote: >>>>> 2009/4/1 jutaro <[email protected]>: >>>>>> 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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > -- > View this message in context: > http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp22816032p22846713.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
