Simon Marlow:
Claus Reinke wrote:
Yes you need to re-install Haddock if you re-install GHC, but
that's just like any other library (think of Haddock as a
library). I think it's unlikely that anyone will want to have
multiple Haddock installations, but if they do then they'll just
have to
- but if that isn't the case:
- ask ghc 6.11 to explain its .hi files in Haskell terms
ghc6.11 --show-iface-haskell libdir/*.hi -hsiodir hsi
- direct ghc-api 6.10 to consult hsi files for missing libs
GAC +RTS -hsidir hsi
So the fundamental problem with this is that when new
Claus Reinke wrote:
- but if that isn't the case:
- ask ghc 6.11 to explain its .hi files in Haskell terms
ghc6.11 --show-iface-haskell libdir/*.hi -hsiodir hsi
- direct ghc-api 6.10 to consult hsi files for missing libs
GAC +RTS -hsidir hsi
So the fundamental problem with
On Tue, 2008-08-19 at 15:33 +0100, Ian Lynagh wrote:
> > Hmm. We want a flag that isn't subject to Cabal's automatic resolution.
> > Duncan, is there any way to do what we want here?
>
> If not, then perhaps adding "manually-en/disabled-only" flags to Cabal
> is the way to go. This would actual
On Tue, 2008-08-19 at 15:05 +0100, Simon Marlow wrote:
> >>> However, haddock would still have to support ghc-paths for standalone
> >>> builds. Also, I think that in a GHC tree we'd still have to pointlessly
> >>> link against ghc-paths, as I can't see a simple way to avoid it.
> >> Can't this be
1 updating ghc-paths and notifying existing clients
2 making (some) ghc api clients less dependent on a single ghcversion
dynamic linking will solve (1), but at this stage I don't think we have
time to get dynamic linking fully working and in the binary distributions
for 6.10.1. We might
>However, haddock would still have to support ghc-paths for standalone
>builds. Also, I think that in a GHC tree we'd still have to pointlessly
>link against ghc-paths, as I can't see a simple way to avoid it.
Can't this be a conditional dependency?
If you have
Flag ghcPaths
if flag(ghc
On Tue, Aug 19, 2008 at 03:05:48PM +0100, Simon Marlow wrote:
>
> I just meant that Haddock already uses Paths_haddock to get the location of
> its own support files,
Oh, I see. Right, so as long as we give relative paths for everything
that'll work for Windows bindists, but we'll need to fix th
Ian Lynagh wrote:
On Windows we'll need to use the usual trick for finding the path relative
to the binary location, but that's standard stuff, and Haddock does it
already
Does it? I'm looking at the http://code.haskell.org/haddock/ repo, and
as far as I can see haddock's getGhcLibDir just lo
On Tue, Aug 19, 2008 at 11:26:24AM +0100, Simon Marlow wrote:
>
> seem so hard to install Haddock with GHC. We have to do the wrapper script
> business for GHC itself anyway and you already added support to Cabal for
> this, so (I imagine) it shouldn't be too hard to do this for Haddock too.
Ian Lynagh wrote:
I've been thinking about haddock 2 and GHC, and it's not clear to me
what the best way forwards is.
Haddock uses ghc-paths to work out where the GHC libdir is. This should
work fine for running haddock in the tree, but it won't work for
installing haddock as
In fact it'll come with the Haskell Platform, and that's feasible
because I don't think we're planning to make relocatable binary
distributions of the HP.
Not having relocatable binary distributions would be sad indeed,
especially as a regression from what we used to have. Being able
to use gh
Claus Reinke wrote:
In fact it'll come with the Haskell Platform, and that's feasible
because I don't think we're planning to make relocatable binary
distributions of the HP.
Not having relocatable binary distributions would be sad indeed,
especially as a regression from what we used to have.
> As I've said before regarding (2), it's feasible to make the .hi
> format stable across minor releases of GHC, but not major releases.
Here is an idea that might help solve some of the "need exact version of
ghc to build haddock" style of problem.
Why not develop a _small_ stand-alone tool th
In fact it'll come with the Haskell Platform, and that's feasible because
I don't think we're planning to make relocatable binary distributions of
the HP.
Not having relocatable binary distributions would be sad indeed,
especially as a regression from what we used to have. Being able
to use gh
Claus Reinke wrote:
Instead of working around them in each individual case, I'd really like
to see general solutions to the two issues of
1 updating ghc-paths and notifying existing clients
2 making (some) ghc api clients less dependent on a single ghcversion
Most suggestions about this h
Manuel M T Chakravarty wrote:
I think the only sane choice is to install haddock with ghc. Some
people may have multiple GHCs installed, some system-wide and some in
their home directory. I think it is generally impossible to guess for
an installer which version of which ghc to use.
Sane bu
27;ve been thinking about haddock 2 and GHC, and it's not clear to me
what the best way forwards is.
Haddock uses ghc-paths to work out where the GHC libdir is. This
should
work fine for running haddock in the tree, but it won't work for
installing haddock as our builds are relocatabl
On Sun, 2008-08-17 at 12:02 +0100, Ian Lynagh wrote:
> I'm not keen on this (if I understand what you mean correctly). On
> systems like Debian we need to be able to just build the GHC package,
> and on systems like gentoo users don't want to have to build GHC twice
> just so that they can get the
On Sun, Aug 17, 2008 at 11:02:54AM +0100, Claus Reinke wrote:
>
> Since dynamic linking is on the table for 6.10 anyway, wouldn't that work?
I don't think we're confident that shared libraries will make it for
6.10.
> >Alternatively, we could build haddock and haddock the libraries, but not
> >s
I've been thinking about haddock 2 and GHC, and it's not clear to me
what the best way forwards is.
Haddock uses ghc-paths to work out where the GHC libdir is. This should
work fine for running haddock in the tree, but it won't work for
installing haddock as our builds are relo
Hi all,
I've been thinking about haddock 2 and GHC, and it's not clear to me
what the best way forwards is.
Haddock uses ghc-paths to work out where the GHC libdir is. This should
work fine for running haddock in the tree, but it won't work for
installing haddock as our builds
Claus Reinke wrote:
Claus is asking that we use an extensible .hi-file format too, to
allow some GHC API clients to work with libraries compiled by a wider
range of GHC versions. I'm not sure how practical that is, though:
what happens when we introduce new type system extensions, so that the
1. We often change .hi-file formats between versions of GHC. I am
very reluctant indeed to deny ourselves this opportunity, because
interface-file flexibility *the* way in which we can convey new
compile-time info across module boundaries.
By all means, *adding* new compile-time info to inte
Claus is asking that we use an extensible .hi-file format too, to allow
some GHC API clients to work with libraries compiled by a wider range of
GHC versions. I'm not sure how practical that is, though: what happens
when we introduce new type system extensions, so that the old GHC API can't
un
Simon Peyton-Jones wrote:
| Please reconsider striving for a form of cross-version compatibility
| that will solve this issue for GHC Api clients, as a priority on par with
| binary compatibility.
...
| Perhaps Haskell' should re-consider the idea of having an
| explicit representation of module
| Please reconsider striving for a form of cross-version compatibility
| that will solve this issue for GHC Api clients, as a priority on par with
| binary compatibility.
...
| Perhaps Haskell' should re-consider the idea of having an
| explicit representation of module interfaces, to get all that
| Please reconsider striving for a form of cross-version compatibility
| that will solve this issue for GHC Api clients, as a priority on par with
| binary compatibility.
...
| Perhaps Haskell' should re-consider the idea of having an
| explicit representation of module interfaces, to get all that
I'm not so sure an automatic translation/simplification of the AST
would be so useful for some tools. For example, say
Wait, how did refactorings get into this?-) The simplifications in
this case are more like eliding details from the AST types, to
represent the same source with different, s
I'm not so sure an automatic translation/simplification of the AST
would be so useful for some tools. For example, say
f x y | Just a <- x, Right a' <- y = foo
| Left b <- y= bar
| otherwise = baz
gets translated to
f x y = case x of
However, until this fundamental issue is addressed, is there any
way to make GHC Api clients less dependent on the details of a specific
GHC Api version? In the scenario given above, if T,
despite being built with GHC V1, was able to work with GHC
V2's Api, then it could use GHC V2's formats des
I think you've veered onto a different (but related) topic here. I was
talking about binary compatibility between libraries, you're talking about
allowing the GHC API to make use of .hi files generated by a different
version of GHC.
Right. I was also assuming that, to link with a library, yo
Claus Reinke wrote:
However, until this fundamental issue is addressed, is there any
way to make GHC Api clients less dependent on the details of a specific
GHC Api version? In the scenario given above, if T,
despite being built with GHC V1, was able to work with GHC
V2's Api, then it could use
Claus Reinke wrote:
I've never found the rationale for GHC's binary incompatibility
very convincing (yes, we want cross-package optimizations, and
yes, we do like it if GHC V(n+1) does a better job at compiling
package P than GHC Vn did; but why can't GHC V(n+1) do
at least as good a job as GHC V
I've never found the rationale for GHC's binary incompatibility
very convincing (yes, we want cross-package optimizations, and
yes, we do like it if GHC V(n+1) does a better job at compiling
package P than GHC Vn did; but why can't GHC V(n+1) do
at least as good a job as GHC Vn with package P comp
Claus Reinke wrote:
I've never found the rationale for GHC's binary incompatibility
very convincing (yes, we want cross-package optimizations, and
yes, we do like it if GHC V(n+1) does a better job at compiling
package P than GHC Vn did; but why can't GHC V(n+1) do
at least as good a job as GHC
(one might like to use a different presentation style for
classes and families, but that is a slightly different matter)
The presentation style is why Haddock needs to know so much about
GHC's language. There are many differences between the pretty printing
requirements of GHC and the HTML o
Haddock reads two types of interface files:
* GHC .hi files
These are needed by the GHC API for all packages that the package
under processing depends on. Otherwise it can't rename and typecheck
the code. We want the code renamed, and in the future it would be nice
to have it typechecked so that o
2008/7/7 Claus Reinke <[EMAIL PROTECTED]>:
>> The problem is that Haddock has to be built with the final GHC
>> version, otherwise it can't use the final version's interface files.
>> So I was just referring to the method of building GHC without docs,
>> then using it to build Haddock and then inst
The problem is that Haddock has to be built with the final GHC
version, otherwise it can't use the final version's interface files.
So I was just referring to the method of building GHC without docs,
then using it to build Haddock and then installing the docs. I was not
referring to any new method
40 matches
Mail list logo
