On 29/08/2008, at 01:31, Simon Marlow wrote:
Roman Leshchinskiy wrote:
On 28/08/2008, at 23:59, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies
is that they can be made sound with not much difficulty. If I say
that my package depends on base==3.0 and ne
On 2008 Aug 28, at 22:00, Sterling Clover wrote:
We do have, although not with easy access, an additional declarative
layer "built in" 90% of the time as configuration as type signature.
Sure? I think it's easier than you think: someone's already written
code to extract the information fro
We do have, although not with easy access, an additional declarative
layer "built in" 90% of the time as configuration as type signature.
An autoconf style approach to this where each type signature
dependency is declared seperately would be needlessly complex and
painful. However, there is
On 29/08/2008, at 03:11, Ian Lynagh wrote:
On Fri, Aug 29, 2008 at 12:57:59AM +1000, Roman Leshchinskiy wrote:
On 28/08/2008, at 21:10, Ian Lynagh wrote:
On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote:
PS: concerning your last point, about "separating the Simple build
sy
On Fri, Aug 29, 2008 at 12:21:10AM +0100, Ian Lynagh wrote:
> You imply you like Cabal's metadata, which says "I depend on network
> version 1", right?
no, I mean a standard way to specify a package name, a description of it,
a category, etc..
> But you don't like Cabal's configuration management
On Thu, Aug 28, 2008 at 03:16:16PM -0700, John Meacham wrote:
> On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote:
>
> > To generate a distro package from an autoconf package either the package
> > author has to include support for that distro, or a distro packager has
> > to write s
On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote:
> The important thing about Cabal's way of specifying dependencies is that
> they can be made sound with not much difficulty. If I say that my
> package depends on base==3.0 and network==1.0, then I can guarantee that
> as long as t
On Fri, Aug 29, 2008 at 12:57:59AM +1000, Roman Leshchinskiy wrote:
> On 28/08/2008, at 21:10, Ian Lynagh wrote:
>
> >On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote:
> >>
> >>PS: concerning your last point, about "separating the Simple build
> >>system", that might indeed be
On 28/08/2008, at 23:59, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies is
that they can be made sound with not much difficulty. If I say that
my package depends on base==3.0 and network==1.0, then I can
guarantee that as long as those dependencies are
Roman Leshchinskiy wrote:
On 28/08/2008, at 23:59, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies is
that they can be made sound with not much difficulty. If I say that
my package depends on base==3.0 and network==1.0, then I can guarantee
that as long a
On 28/08/2008, at 21:10, Ian Lynagh wrote:
On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote:
PS: concerning your last point, about "separating the Simple build
system", that might indeed be good. Indeed, the GHC plan described
here http://hackage.haskell.org/trac/ghc/wik
On 28/08/2008, at 19:27, Simon Peyton-Jones wrote:
Duncan, I'm not following every detail here, but it's clear that you
have some clear mental infrastructure in your head that informs and
underpins the way Cabal is. Cabal "takes the view that...", has
"principles", and "is clearly partiti
| Yes this means that Cabal is less general than autoconf. It was quite a
| revelation when we discovered this during the design of Cabal - originally
| we were going to have everything done programmatically in the Setup.hs
| file, but then we realised that having the package configuration availab
On 2008 Aug 28, at 5:27, Simon Peyton-Jones wrote:
This isn't a criticism: one of the hardest thing to do is to
accurately convey this underwater stuff. But I wonder whether there
might be a useful paper hiding here? Something that establishes
terminology, writes down principles, explains
John Meacham wrote:
unfortunately the cabal approach doesn't work. note, I am not saying a
declarative configuration manager won't work. in fact, I have sketched a
design for one on occasion. but cabal's particular choices are broken.
It is treading the same waters that made 'imake' fail.
the i
On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote:
>
> PS: concerning your last point, about "separating the Simple build system",
> that might indeed be good. Indeed, the GHC plan described here
> http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is (I think)
> prec
| So Cabal takes the view that the relationship between features and
| dependencies should be declarative.
...
| The other principle is that the packager, the environment is in control
| over what things the package 'sees'.
...
| that we can and that the approach is basically sound. The fact that w
John Meacham wrote:
> On Wed, Aug 27, 2008 at 10:18:59PM +0100, Duncan Coutts wrote:
> > So I accept that we do not yet cover the range of configuration
> > choices that are needed by the more complex packages (cf darcs), but
I
> > think that we can and that the approach is basically sound. The
18 matches
Mail list logo
