Hi Hamish, Am Freitag, den 07.05.2010, 02:31 +1200 schrieb Hamish Mackenzie: > On 7 May 2010, at 00:43, Joachim Breitner wrote: > > > The comparison with cabal-install is not valid. cabal-install’s main > > feature is to download stuff (like an ftp client), while leksah’s main > > feature is to edit Haskell code. Imaging that kate would require an > > Internet connection to be able to highlight your code... > > First start dialog does present the user with the URL and the option > to turn it off. You could default it to disabled if you wish, but it > means the default URL will not be available either (I think it is a > Maybe String). I think it is ok to be default on, now that users will plainly see what is happening. > > Also, are you providing the metadata for each and every version on > > leksah.org? Once Debian releases, the versions of the included Haskell > > libraries are not going to change for two or more years... > > In a perfect would metadata would be built on hackage or at least > triggered by messages from hackage. I was more referring to backwards compatibility: How long do you store the metadata? Do you clean up from time to time? If you’d make http://leksah.org/metadata-0.8/ indexable, I’d have a look myself :-) > > Therefore, I’d like to include the metadata that leksah needs within the > > haskell library package. Therefore the question: If .kshm-files are > > generated upon building a library, and shipped along, is that enough to > > make leksah happy? > > If you can make this work it would be great. I’m skeptical, but I’m evaluating the options. One big problem is cyclical dependencies. Assume we start building libraries including leksah meta data. Then leksah-server would be a build dependency for every haskell package. But to build leksah-server, we need to build mtl first – a classical chicken-and-egg problem. For tools like hscolour, it is not too bad, because they have no dependencies besides ghc6. Now this could be worked around by manually bootstrapping leksah once. Or by making the build not fail if no leksah is available, and then “bootstrap” packages with a “dummy leksah” package. Or something like this – our problem :-) I’m still doubtful that the ghc6 maintainer will be willing to add another dependency, so for the libraries shipped with ghc6, we have to think of something else. > lkshm files alone should be fine (lkshp files will be generated > locally). I think our main concern is that it may be difficult. > > You should be able to make the metadata by running "leksah-server -so" > as part of your library build script. You will need to make sure > ~/.leksah-0.8/prefs.lkhsp on the build machine is set up to look in > the appropriate source directories. Ideally, we’d have a leksah-make-lkhsp package that has minimal dependencies (no network stuff etc) and requires no configuration, so that I can run it – just like hscolour or haddock – from within the source tree and tell it where to put the .lkhsp file. > Jurgen and I will need to make a small change to leksah to have it > check its data directory for metadata (currently it only looks in > ~/.leksah-0.8/metadata). This will give you somewhere to put the > haskell-debian metadata. I'll try to do that this weekend. Yes, that would be great. > You will need to make sure that both leksah and leksah-server are > built with the same data --datasubdir setting (so they can both see > the lkshm files). What is the difference between --datasubdir and the system-wide alternative to ~/.leksah-0.8/metadata you mentioned in the paragraph before? > Will there be a fast way for users to get all the source for there > debian haskell packages onto their system? Not likely. But why do you need the sources if you have lkshp-files? I still think it would be great if you could make the .lkshp generating a plugin to cabal, so that users (not only of Debian) automatically get the .lkshp file when building with anything with cabal (of course configurably). Cabal can also provide you with pre-processed source files, where required. Another strange idea: Maybe you can make a haddock wrapper that will extend it to write .lkhsp files along .haddock files when called with -D? (My goal is to have .lkhsp files always generated when a package is build: On the Debian build hosts when using a pre-built package; by cabal when using cabal build or cabal install – I hope this vision makes sense to you :-)) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part