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'
Hello,
On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
<[EMAIL PROTECTED]> wrote:
>> cabal-install: it does not work well with packages that have flags
>> because it does not know what flags to use when building dependencies.
>> Really, packages with conditionals are different packages in one
>> ca
> > cabal-install: it does not work well with packages that have flags
> > because it does not know what flags to use when building dependencies.
> > Really, packages with conditionals are different packages in one
> > cabal file.
>
> Packages are not supposed to expose different APIs with differe
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
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
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
> | fil
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'.
> ..
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 sys
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 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
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
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
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 ne
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 e
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,
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
tuit
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 fo
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 Distributi
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 descrip
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 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 wr
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 sy
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 b
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 don'
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 generat
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 package-speci
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 package-specific metadata (list of mod
Duncan Coutts:
On Tue, 2008-08-12 at 11:11 +0100, Simon Marlow wrote:
I propose we do this:
- 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
> Simon PJ and I had a talk about the build system earlier today, I thought
> I'd float the idea we discussed...
> I propose we do this:
>
> - Extract the code from Cabal that generates Makefiles, and treat it as
> part of the GHC build system. Rather than generating a Makefile
>
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 sam
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 approach that nhc98
On Tue, 2008-08-12 at 11:11 +0100, Simon Marlow wrote:
> I propose we do this:
>
> - 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
>
Simon PJ and I had a talk about the build system earlier today, I thought
I'd float the idea we discussed (I should admit that the idea was mine,
lest Simon PJ think I'm attributing bad ideas to him :-). This is not
completely thought through, but I'm pretty sure a solution exists along
these
50 matches
Mail list logo
