Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonmar):
Looks ok to me, though the difference between ghc-pkg dump and ghc-pkg
describe is slightly worrisome. That means `ghc-pkg describe | ghc-pkg
update` is not the identity (I think we have a test that will break).
What goes wrong if `ghc-pkg describe` uses `--no-expand-vars` by default?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by duncan):
Replying to [comment:8 simonmar]:
Looks ok to me, though the difference between ghc-pkg dump and ghc-pkg
describe is slightly worrisome. That means `ghc-pkg describe | ghc-pkg
update` is not the identity (I think we have a test that will break).
It doesn't break yet because nothing uses ${pkgroot}. But yes, it'd have
to be updated to use `--no-expand-pkgroot`.
What goes wrong if `ghc-pkg describe` uses `--no-expand-vars` by
default?
It's simply that it'll surprise people and perhaps existing tools. I'm
happy to give it a go and see what breaks :-)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by duncan):
Ok, so we'll make both `dump` and `describe` use the unexpanded form by
default and provide `--expand-pkgroot` which should generate the previous
format exactly.
`ghc-pkg field` will by default expand the `${pkgroot}` but that can be
altered via `--no-expand-pkgroot`.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:10
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
--+-
Reporter: duncan | Owner:
Type: feature request | Status: closed
Priority: normal | Milestone: 7.2.1
Component: Package system |Version: 6.10.2
Resolution: fixed| Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by duncan):
* status: new = closed
* resolution: = fixed
Comment:
Done!
{{{
commit 40b6bd47cf00f025426746bbd7abdd0eda2a3afd
Author: Duncan Coutts dun...@well-typed.com
Date: Mon May 23 22:10:45 2011 +0100
Implement ${pkgroot} spec, allows relocatable registered packages
Historically ghc implemented relocatable packages by allowing
$topdir in the package registration info and having ghc expand
this with its notion of $topdir. The topdir refers to where ghc
itself is installed (specifically the libdir).
The ${pkgroot} spec takes this idea and makes it portable.
(http://www.haskell.org/pipermail/libraries/2009-May/011772.html)
Instead of paths relative to where ghc is installed, they can be
relative to the package database itself. Thus it is no longer a
ghc-specific idea and can work for package collections other than
the global package db.
commit f35a3d247e023b6c1b0abe677549b29398933b50
Author: Duncan Coutts dun...@well-typed.com
Date: Wed May 25 13:06:14 2011 +0100
Provide the pkgroot value in ghc-pkg dump describe when necessary
Tools handling installed packages need to be able to interpret the
paths which are relative to the ${pkgroot} which means they need to
know the value of ${pkgroot}. With ghc-pkg this is not always obvious
since ghc-pkg does not currently have any way machine interface for
reporting the location of its package dbs (global, user). The solution
we have arrived at is simply to emit the pkgroot as an extra field
when it is needed.
There are two cases:
* --no-expand-pkgroot: ghc-pkg dump/describe will not expand the
${pkgroot} var, so it will appear literally in the output and the
pkgroot field will be generated so that tools know what value to
use for the ${pkgroot}.
* --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot}
and ${pkgrooturl} vars and will not generate the pkgroot field.
The defaults are:
* ghc-pkg dump/describe --no-expand-pkgroot
* ghc-pkg field --expand-pkgroot
}}}
Also implemented in Cabal:
{{{
Wed May 25 12:47:42 BST 2011 Duncan Coutts dun...@community.haskell.org
* Support ${pkgroot}-relative paths in installed package info from hc-
pkg
See http://hackage.haskell.org/trac/ghc/ticket/3268
In new versions of ghc-pkg, ghc-pkg dump will emit an extra field like
pkgroot: /the/path/that/is/the/pkgroot
and other fields may contain ${pkgroot}, e.g.
library-dirs: ${pkgroot}/blah/
This allows relocatable packages, with package files installed
relative to the package database itself.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by duncan):
Replying to [comment:2 duncan]:
* for `ghc-pkg dump`, we prefix each batch of packages with the
`pkgroot` value
(choosing some suitable syntax)
Yes. Some suitable syntax we've not yet chosen :-)
I've decided that the simplest thing to do is to just have it as an extra
field:
{{{
pkgroot: /the/path/that/is/the/pkgroot
}}}
So this field may be in the output, but never in the input (if it is it's
ignored like all other unknown fields).
There are two cases:
* `--expand-vars`: in this case `ghc-pkg dump`/`describe` will expand the
`${pkgroot}` and `${pkgrooturl}` vars and will not generate the `pkgroot`
field.
* `--no-expand-vars`: in this case `ghc-pkg dump`/`describe` will not
expand the `${pkgroot}` var, so it will appear literally in the output and
the `pkgroot` field will be generated so that tools know what value to use
for the `${pkgroot}`.
The defaults are:
* `ghc-pkg dump` uses `--no-expand-vars` by default, but this can be
reversed with `--expand-vars`
* `ghc-pkg describe` uses `--expand-vars` by default, but this can be
reversed with `--no-expand-vars`
(Alternatively could be more explicit and say `-(no-)expand-pkgroot`.)
Sound sane?
None of this applies to hugs/nhc style file databases because there tools
always know exactly what the pkgroot is, as it's just the dir containing
the file they read. Because `ghc-pkg` has a looser connection between the
package info and the locations they come from then we need this (or a
similar) extra mechanism.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
--+-
Reporter: duncan | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 6.14.1
Component: Package system |Version: 6.10.2
Resolution: | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by igloo):
* failure: = None/Unknown
* milestone: 6.12.1 = 6.14.1
Comment:
See also #3072.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 6.12.1
Component: Package system| Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by igloo):
* milestone: = 6.12.1
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Package system| Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by duncan):
Replying to [comment:1 simonmar]:
After discussion with Duncan, we decided to
* implement `ghc-pkg pkgroot package`, which returns the value of
`${pkgroot}`
for the given package
Oh, sorry, I wasn't clear. I don't think this is necessary. But if you
want to do it anyway I'm not going to say no.
* for `ghc-pkg dump`, we prefix each batch of packages with the
`pkgroot` value
(choosing some suitable syntax)
Yes. Some suitable syntax we've not yet chosen :-)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Package system| Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by simonmar):
* difficulty: = Unknown
Comment:
After discussion with Duncan, we decided to
* implement `ghc-pkg pkgroot package`, which returns the value of
`${pkgroot}`
for the given package
* for `ghc-pkg dump`, we prefix each batch of packages with the `pkgroot`
value
(choosing some suitable syntax)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan| Owner:
Type: feature request | Status: new
Priority: normal| Component: Package system
Version: 6.10.2| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
See the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and
`$httptopdir` with variables that are interpreted relative to the package
db file itself rather than relative to where ghc is installed (though for
the global package db these coincide).
The open question is how tools discover the location of the package dbs.
The proposed spec extension does not specify this, but perhaps it should
specify an extension to (the hypothetical) `hc-pkg` system to discover the
default set of package dbs and their paths.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
