Just cleaning out my inbox and realised I meant to reply to this about 4
months ago :-)
On Thu, 2008-09-04 at 23:15 -0700, Iavor Diatchki wrote:
On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
Packages are not supposed to expose different APIs with different
flags
so I don't think that's
Hi,
On Thu, Aug 28, 2008 at 6:59 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Because if you *can* use Cabal, you get a lot of value-adds for free (distro
packages, cabal-install, Haddock, source distributions, Hackage). What's
more, it's really cheap to use Cabal: a .cabal file is typically less
On Thu, 2008-09-04 at 09:59 -0700, Iavor Diatchki wrote:
Hi,
On Thu, Aug 28, 2008 at 6:59 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Because if you *can* use Cabal, you get a lot of value-adds for free (distro
packages, cabal-install, Haddock, source distributions, Hackage). What's
more,
On Thu, 2008-08-28 at 10:27 +0100, Simon Peyton-Jones wrote:
| 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'.
...
|
On Thu, 2008-08-28 at 15:02 +0100, Simon Peyton-Jones wrote:
| 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,
Hi John,
I've extracted among others two things you don't like too much about
cabal:
a) having to specify build dependencies because they may change
(eg example split base or different libraries poviding network
interfaces ..)
b) Cabal can't do everything easily. Examples are the multi stage
John Meacham wrote:
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
Brandon S. Allbery KF8NH wrote:
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
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 fact
| 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
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)
precisely
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
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
| 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
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 partitioned
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
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
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
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 good. Indeed,
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
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 specific
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 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
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 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 from
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
On Wed, Aug 13, 2008 at 01:31:55PM +1000, Roman Leshchinskiy wrote:
This makes me wonder, though. Wouldn't this model make more sense for
Cabal in general than the current approach of duplicating the
functionality of autoconf, make and other stuff? If it works ghc, it
ought to work for
John Meacham [EMAIL PROTECTED] wrote:
(bring back hmake! :) ).
It never went away...
http://www.cs.york.ac.uk/fp/hmake
I even have the idea to allow hmake to read the .cabal file format for
configuration data (although that is waiting for a delivery of round
On Wed, 2008-08-27 at 03:04 -0700, John Meacham wrote:
On Wed, Aug 13, 2008 at 01:31:55PM +1000, Roman Leshchinskiy wrote:
This makes me wonder, though. Wouldn't this model make more sense for
Cabal in general than the current approach of duplicating the
functionality of autoconf, make
The problem with the way cabal wants to mix with make/autoconf is that
it is the wrong way round. make is very good at managing pre-processors,
dependency tracking and calling external programs in the right order, in
parallel, and as needed. cabal is generally good at building a single
library or
On Wed, 2008-08-27 at 06:13 -0700, John Meacham wrote:
The problem with the way cabal wants to mix with make/autoconf is that
it is the wrong way round. make is very good at managing pre-processors,
dependency tracking and calling external programs in the right order, in
parallel, and as
On Wed, Aug 27, 2008 at 10:18:59PM +0100, Duncan Coutts wrote:
On Wed, 2008-08-27 at 06:13 -0700, John Meacham wrote:
The problem with the way cabal wants to mix with make/autoconf is that
it is the wrong way round. make is very good at managing pre-processors,
dependency tracking and
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is really
unnecessary and could be done by Cabal since it only or mostly depends
on the package information. Instead, it is implemented somewhere in
Distribution.Simple and not really usable from the outside.
On 14/08/2008, at 06:32, Duncan Coutts wrote:
On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
Again, I'm not arguing against a build system written in Haskell. I'd
just like it to be completely separated from Haskell's packaging
system. In particular, polluting a package
On 14/08/2008, at 18:01, Simon Marlow wrote:
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is
really unnecessary and could be done by Cabal since it only or
mostly depends on the package information. Instead, it is
implemented somewhere in
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generate a Makefile that just
has the
On 13/08/2008, at 17:47, Simon Marlow wrote:
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat
it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple packages.
It could be part of Cabal or a separate tool (for which Cabal could,
again, act as a preprocessor).
GHC is a special case: we already need a build system for other reasons.
I agree. I just
On Wed, 2008-08-13 at 11:34 +0100, Simon Marlow wrote:
Cabal has two parts: some generic infrastructure, and a simple build
system (under Distribution.Simple) that suffices for most packages. We
distribute them together only because it's convenient; you don't have to
use the simple build
On 13/08/2008, at 20:34, Simon Marlow wrote:
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple
packages. It could be part of Cabal or a separate tool (for which
Cabal could, again, act as a preprocessor).
GHC is a special case: we already need a build
On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
Again, I'm not arguing against a build system written in Haskell. I'd
just like it to be completely separated from Haskell's packaging
system. In particular, polluting a package description with build
information seems wrong
Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
This means we still get to use 'make', we still get to use the .cabal
files as metadata, but the build system is more private to GHC, more
extensible, and hopefully more understandable and modifiable.
This is essentially the same
42 matches
Mail list logo
