headers
Simon Marlow | 12 Aug 12:08

Build system idea

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 lines that would improve things for us.

Ok, the starting point is this:

  - Cabal has code to generate Makefiles.  Almost nobody uses it except
    for the GHC build system.  It essentially duplicates the build system
    for compiling Haskell source (but not for installation, haddocking,
    registration, configuration, etc.)

  - Cabal is a library

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
    has the package-specific metadata (list of modules, etc.), and put
    the code to actually build the package in the GHC build system.

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.  We can express 
dependencies that Cabal currently doesn't know about.  It would let us 
avoid the current uncomfortable situation where we have to feed all kinds 
of configuration information from the GHC build system into Cabal - Cabal 
would be essentially just a mechanism for translating the .cabal file into
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 12 Aug 13:09
Gravatar

Re: Build system idea

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
>     has the package-specific metadata (list of modules, etc.), and put
>     the code to actually build the package in the GHC build system.

As you know, I've been trying to get rid of that code ever since it
arrived :-)

> It will probably mean that we have a tighter dependency on Cabal, because 
> we use it as a library rather than a black box; but hopefully we can keep 
> our branch of Cabal more stable and not have to update it so often.

If you don't need to update so often it would make life easier for Cabal
hackers and Manuel would be pleased :-)

> Anyway, this is an idea that I think is interesting.  Obviously it needs a 
> lot more fleshing out to be a real proposal, but I'm interested in whether 
> anyone thinks this idea is worth persuing, or whether there are better 
> alternatives.

Right, so probably the crucial thing is how much you end up having to
duplicate and of how much of said duplicated infrastructure has to be
kept in sync. For example if the path layout is different does that make
Cabal's haddocking support not work forcing that to be duplicated too?
(Continue reading)

Permalink | Reply |
headers
Manuel M T Chakravarty | 13 Aug 02:27
Favicon
Gravatar

Re: Build system idea

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 just
>>    has the package-specific metadata (list of modules, etc.), and put
>>    the code to actually build the package in the GHC build system.
>
> As you know, I've been trying to get rid of that code ever since it
> arrived :-)
>
>> It will probably mean that we have a tighter dependency on Cabal,  
>> because
>> we use it as a library rather than a black box; but hopefully we  
>> can keep
>> our branch of Cabal more stable and not have to update it so often.
>
> If you don't need to update so often it would make life easier for  
> Cabal
> hackers and Manuel would be pleased :-)

Yes!

>> Anyway, this is an idea that I think is interesting.  Obviously it  
>> needs a
>> lot more fleshing out to be a real proposal, but I'm interested in
(Continue reading)

Permalink | Reply |
headers
Malcolm Wallace | 12 Aug 13:09

Re: Build system idea

Simon Marlow <marlowsd <at> gmail.com> 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 currently takes to
building libraries.  The Cabal file holds all the metadata, but the
build system is Makefile-driven.  There is a small separate tool
(CabalParse) that extracts metadata from the cabal file.  The Cabal
*library* could be used to implement that extraction tool, but currently
ours is hand-rolled.  (One of the benefits of open specifications of
file formats is that you can have multiple implementations for different
purposes.)

Here is an example of how it works:

CABALFILE  = $(shell ls *.cabal | head -n 1 )
READ       = $(CABALPARSE) $(CABALFILE) -quiet
MAP        = $(LOCAL)map

THISPKG    = $(shell $(READ) name | cut -c2- )
VERSION    = $(shell $(READ) version)
SEARCH     = $(shell $(READ) build-depends  | $(MAP) "echo -package" ) \
             $(shell $(READ) include-dirs   | $(MAP) "echo -i" | cut -c1,2,4-) \
             $(shell $(READ) hs-source-dir  | $(MAP) "echo -I" | cut -c1,2,4-) \
             $(shell $(READ) hs-source-dirs | $(MAP) "echo -I" | cut -c1,2,4-)
CINCLUDES  = $(shell $(READ) include-dirs   | $(MAP) "echo -I" | cut -c1,2,4-)
SRCS       = $(shell $(READ) -slash exposed-modules)
EXTRA_SRCS = $(shell $(READ) -slash other-modules)
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 12 Aug 14:55

Re: Build system idea

Malcolm Wallace wrote:
> Simon Marlow <marlowsd <at> gmail.com> 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 currently takes to
> building libraries.

Right, I was aware that nhc98 uses this method but forgot to mention it. 
Thanks for pointing it out.

I think it makes a lot more sense for us to re-use parts of Cabal than to 
re-implement the whole thing, although the balance is probably different 
for nhc98.  Cabal generates the InstalledPackageInfo from the .cabal file, 
for example, and this is certainly something we don't want to re-implement.

Cheers,
	Simon
Permalink | Reply |
headers
Norman Ramsey | 12 Aug 20:57

Re: Build system idea

 > 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
 >     complete with build rules, we generate a Makefile that just
 >     has the package-specific metadata (list of modules, etc.), and put
 >     the code to actually build the package in the GHC build system.
 > 
 > 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...
 >
 > ... I'm interested in whether anyone thinks this idea is worth
 > persuing, or whether there are better alternatives.

Simon,

This direction sounds very promising.  I hope you will keep us posted.

Norman
Permalink | Reply |
headers
Ian Lynagh | 13 Aug 00:24
Gravatar

Re: Build system idea

On Tue, Aug 12, 2008 at 11:11:38AM +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
>    has the package-specific metadata (list of modules, etc.), and put
>    the code to actually build the package in the GHC build system.

Do you see this as the long-term, final solution? Or would the plan be
to let Cabal do the building again once it has learnt how to do its own
dependency analysis and call "ghc -c" on individual modules?

Thanks
Ian
Permalink | Reply |
headers
Simon Marlow | 13 Aug 12:53

Re: Build system idea

Ian Lynagh wrote:
> On Tue, Aug 12, 2008 at 11:11:38AM +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
>>    has the package-specific metadata (list of modules, etc.), and put
>>    the code to actually build the package in the GHC build system.
> 
> Do you see this as the long-term, final solution? Or would the plan be
> to let Cabal do the building again once it has learnt how to do its own
> dependency analysis and call "ghc -c" on individual modules?

Right, it sounds like Cabal's long-term strategy is to provide an 
extensible make DSL, which would address most of the complaints about the 
current system.  Migrating to that in due course should be our long-term plan.

Cheers,
	Simon
Permalink | Reply |
headers
Roman Leshchinskiy | 13 Aug 05:31
Favicon

Re: Build system idea

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 modules, etc.), and put
>   the code to actually build the package in the GHC build system.

Sounds good. It would be nice if the .cabal parser from Cabal could be  
made into a separate, stable library which ghc (and nhc?) could use.

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 other projects, too. Cabal as a preprocessor seems  
much more attractive to me than as a universal build system.

Roman
Permalink | Reply |
headers
Simon Marlow | 13 Aug 09:47

Re: Build system idea

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-specific metadata (list of modules, etc.), and put
>>   the code to actually build the package in the GHC build system.
> 
> Sounds good. It would be nice if the .cabal parser from Cabal could be 
> made into a separate, stable library which ghc (and nhc?) could use.
> 
> 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 other projects, too. Cabal as a preprocessor seems 
> much more attractive to me than as a universal build system.

So packages would be required to provide their own build system?  That 
sounds like it would make it a lot harder for people to just create a 
package that others can use.  The ease of making a Cabal package has I 
think a lot to do with the wealth of software available on Hackage.

GHC is a special case: we already need a build system for other reasons.

It was a design decision early on with Cabal that we didn't want to rely 
on the target system having a Unix-like build environment.  You might 
disagree with this, but it certainly has some value: a Windows user can 
download GHC and immediately start building and installing external 
packages without having to install Cygwin.
(Continue reading)

Permalink | Reply |
headers
Roman Leshchinskiy | 13 Aug 10:51
Favicon

Re: Build system idea

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 generate a Makefile that just
>>>  has the package-specific metadata (list of modules, etc.), and put
>>>  the code to actually build the package in the GHC build system.
>> Sounds good. It would be nice if the .cabal parser from Cabal could  
>> be made into a separate, stable library which ghc (and nhc?) could  
>> use.
>> 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 other projects, too. Cabal as a preprocessor  
>> seems much more attractive to me than as a universal build system.
>
> So packages would be required to provide their own build system?   
> That sounds like it would make it a lot harder for people to just  
> create a package that others can use.  The ease of making a Cabal  
> package has I think a lot to do with the wealth of software  
> available on Hackage.

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
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 13 Aug 12:34

Re: Build system idea

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't think that adding a full-fledged build system to 
> Cabal is the solution. In my experience, huge monolithic tools which try 
> to do everything never work well. I much prefer small, modular tools. A 
> Haskell-based build system is an interesting project but why does it 
> have to be a part of Cabal?

Hmm, but you said above "there should be a standard build system for simple 
packages.  It could be part of Cabal...".

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 system if you don't want to.

I think perhaps you're objecting to the fact that the "simple" build system 
isn't so simple, and we keep adding more functionality to it.  This is 
true, but the alternative - forcing some packages to provide their own 
build system - seems worse to me.

Cheers,
	Simon
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 13 Aug 13:09
Gravatar

Re: Build system idea

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 system if you don't want to.

The two parts also have different degrees of stability. In particular
there are lots of tools that rely on the declarative parts, the types
and parsers so we try not to break those so often. Roman asks for a
"separate, stable library which ghc (and nhc?) could use" but since this
part of Cabal is fairly stable I don't think it needs to be separate. I
don't think it'd be more stable by being in a different package. The
reasons to change it are usually to add new fields, and that usually
does not affect clients that do not need to know about the new fields.

> I think perhaps you're objecting to the fact that the "simple" build system 
> isn't so simple, and we keep adding more functionality to it.  This is 
> true, but the alternative - forcing some packages to provide their own 
> build system - seems worse to me.

As Isaac used to say, it's not the Simple build system because it's
simple. It's because it does complex things to simple packages.

The Make build type was supposed to let people wrap existing make-based
build systems. Unfortunately it's not used much so is not well developed
and for ghc is really the wrong way round. I think your approach of
exporting the info in make syntax makes more sense for ghc, since it's
not trying to pretend it's a cabal package anyway (which is what the
Make build type was for, wrapping things up so people building packages
(Continue reading)

Permalink | Reply |
headers
Roman Leshchinskiy | 13 Aug 14:47
Favicon

Re: Build system idea

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 system for other  
>>> reasons.
>> I agree. I just don't think that adding a full-fledged build system  
>> to Cabal is the solution. In my experience, huge monolithic tools  
>> which try to do everything never work well. I much prefer small,  
>> modular tools. A Haskell-based build system is an interesting  
>> project but why does it have to be a part of Cabal?
>
> Hmm, but you said above "there should be a standard build system for  
> simple packages.  It could be part of Cabal...".

On second thought, it shouldn't be part of Cabal :-)

> 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 system if you don't want to.

My impression of Cabal is that it is a build system with a bit of  
generic infrastructure. In particular, a large part of the .cabal  
syntax is specified in terms of this build system and some of it only  
really makes sense for this build system.
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 13 Aug 22:32
Gravatar

Re: Build system idea

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 to me.

There is a huge overlap of course. The things needed to build a package
tend to be the dependencies. The ability to automatically extract the
dependencies from a package description is crucial as it is what enables
automatic package management either directly or by conversion to distro
packages. Tools like automake + autoconf do not give us that.

There is of course some separation possible, which in Cabal roughly
corresponds to the stuff under Distribution.Simple vs everything else.
We could split those two aspects into separate packages but it's not
clear to me that we'd gain much by doing that.

There is still the Make build type which we could improve if people want
it. That allows the declarative stuff to be given in the .cabal file (so
that package managers can do their thing) and all the building is
delegated to make. People have not shown any interest in this so it's
never been improved much. The obvious disadvantage of using it is that
you have to do a lot of work to make your build system do all the things
that users expect.

Duncan
Permalink | Reply |
headers
Roman Leshchinskiy | 14 Aug 05:05
Favicon

Re: Build system idea

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 description with build
>> information seems wrong to me.
>
> There is a huge overlap of course. The things needed to build a  
> package
> tend to be the dependencies. The ability to automatically extract the
> dependencies from a package description is crucial as it is what  
> enables
> automatic package management either directly or by conversion to  
> distro
> packages. Tools like automake + autoconf do not give us that.

Right. Dependencies are part of a package description. That's what  
Cabal should do. It should provide a nice clean interface to the  
dependencies stuff for the build system to use. I don't think it does  
that at the moment; IIUC, it is all done by Distribution.Simple.

> There is of course some separation possible, which in Cabal roughly
> corresponds to the stuff under Distribution.Simple vs everything else.
> We could split those two aspects into separate packages but it's not
> clear to me that we'd gain much by doing that.

My point isn't really about distribution, it's about coupling. My  
concern is that the syntax of .cabal files is increasingly based on
(Continue reading)

Permalink | Reply |
headers
John Meacham | 27 Aug 12:04
Favicon

Re: Build system idea

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 other projects, too. Cabal as a preprocessor seems  
> much more attractive to me than as a universal build system.

I can't tell you how much I agree with this. the fact that cabal wants
to be my build system as well as my configuration system means it is
pretty much unusable to me in my projects.

Features are something that _hurts_ a system such as this. between a
build system, a configuration manager, a packaging system, etc, it is
rare for any large project that at least one isn't imposed on you by
some external constrant or just a better choice for the job. I would
much rather see cabals functionality split among a variety of different
programs so the pieces can be used when appropriate, not as an all or
nothing thing. (bring back hmake! :) ).

        John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈
Permalink | Reply |
headers
Malcolm Wallace | 27 Aug 12:32

Re: Build system idea

John Meacham <john <at> repetae.net> 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
tuits).

Regards,
    Malcolm
Permalink | Reply |
headers
Duncan Coutts | 27 Aug 12:45
Gravatar

Re: Build system idea

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 and other stuff? If it works ghc, it  
> > ought to work for other projects, too. Cabal as a preprocessor seems  
> > much more attractive to me than as a universal build system.
> 
> I can't tell you how much I agree with this. the fact that cabal wants
> to be my build system as well as my configuration system means it is
> pretty much unusable to me in my projects.
> 
> Features are something that _hurts_ a system such as this. between a
> build system, a configuration manager, a packaging system, etc, it is
> rare for any large project that at least one isn't imposed on you by
> some external constrant or just a better choice for the job. I would
> much rather see cabals functionality split among a variety of different
> programs so the pieces can be used when appropriate, not as an all or
> nothing thing. (bring back hmake! :) ).

People are of course still free to use autoconf and make to implement
their own build system and have it still be a Cabal package (which has
the advantage of presenting the same meta-data and command interface to
packaging tools). It's been that way since the original design. Quite a
few packages to use autoconf though the use seems to be slightly on the
decline as people try and make their packages portable to Windows. Very
few packages use make as it involves re-implementing their own build
system which is a lot of work. That's partly a self-fulfilling prophecy
of course because nobody uses that interface so it does not get improved
so nobody uses it etc. Also, as far as I'm aware hmake still works, at
(Continue reading)

Permalink | Reply |
headers
John Meacham | 27 Aug 15:13
Favicon

Re: Build system idea

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 executable given relatively straightforward haskell source.
(I know it _can_ do more, but this is mainly what it is good at).

The way this should work is that make determines what haskell libraries
need to be built, and what haskell files need to be generated to allow
cabal to run and calls cabal to build just the ones needed. cabal as a
build tool that make calls is much more flexible and in tune with each
tools capabilities.

The other issue is with cabal files themselves which are somewhat
conflicted in purpose. on one hand, you have declarative stuff about a
package. name, version, etc... information you want before you start to
build something. but then you have build-depends, which is something
that you cannot know until after your configuration manager (whatever it
may be, autoconf being a popular one) is run. What packages you depend
on are going to depend on things like what compiler you have installed,
your configuration options, which packages are installed, what operating
system you are running on, which kernel version you are running, which c
libraries you have installed. etc. things that cannot be predicted
before the configuration is actually run.

Then you have cabal as a packaging system (or perhaps hackage/cabal
considered together). Which has its own warts, if it is meant to live in
the niche of package managers such as rpm or deb, where are the
'release' version numbers that rpms and debs have for one example? If it is
meant to be a tarball like format, where is the distinction between
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 27 Aug 23:18
Gravatar

Re: Build system idea

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 needed. cabal is generally good at building a single
> library or executable given relatively straightforward haskell source.
> (I know it _can_ do more, but this is mainly what it is good at).
> 
> The way this should work is that make determines what haskell libraries
> need to be built, and what haskell files need to be generated to allow
> cabal to run and calls cabal to build just the ones needed. cabal as a
> build tool that make calls is much more flexible and in tune with each
> tools capabilities.

I'd say if you're using make for all that, then use it to build the
haskell modules too. That gives the advantage of incremental and
parallel builds, which Cabal does not do yet (though we've got a GSoC
project just coming to an end which does this).

> The other issue is with cabal files themselves which are somewhat
> conflicted in purpose. on one hand, you have declarative stuff about a
> package. name, version, etc... information you want before you start to
> build something. but then you have build-depends, which is something
> that you cannot know until after your configuration manager (whatever it
> may be, autoconf being a popular one) is run.

Ah, but that's where the autoconf and Cabal models part ways.

> What packages you depend on are going to depend on things like what
> compiler you have installed, your configuration options, which
(Continue reading)

Permalink | Reply |
headers
John Meacham | 28 Aug 04:26
Favicon

Re: Build system idea

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 calling external programs in the right order, in
> > parallel, and as needed. cabal is generally good at building a single
> > library or executable given relatively straightforward haskell source.
> > (I know it _can_ do more, but this is mainly what it is good at).
> >
> > The way this should work is that make determines what haskell libraries
> > need to be built, and what haskell files need to be generated to allow
> > cabal to run and calls cabal to build just the ones needed. cabal as a
> > build tool that make calls is much more flexible and in tune with each
> > tools capabilities.
>
> I'd say if you're using make for all that, then use it to build the
> haskell modules too. That gives the advantage of incremental and
> parallel builds, which Cabal does not do yet (though we've got a GSoC
> project just coming to an end which does this).

So, don't use cabal at all? that is the solution I have been going with so
far and am trying to remedy.

> > The other issue is with cabal files themselves which are somewhat
> > conflicted in purpose. on one hand, you have declarative stuff about a
> > package. name, version, etc... information you want before you start to
> > build something. but then you have build-depends, which is something
> > that you cannot know until after your configuration manager (whatever it
> > may be, autoconf being a popular one) is run.
>
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 28 Aug 15:59

Re: Build system idea

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 ideas of forwards and backwards compatability are _the_ defining
> features of a configuration manager. Think about this, I can take my old
> sunsite CD, burned _ten years_ ago and take the unchanged tarballs off
> that CD and ./configure && make and in general most will work. many were
> written before linux even existed, many were written with non gcc
> compilers, yet they work today. The cabal way wasn't able to handle a
> single release of ghc and keep forwards or backwards compatability.
> 
> That any project ever had to be changed to use the flag 'split-base' is
> a travesty. What about all the projects on burnt cds or that don't have
> someone to update them? 20 years from now when we are all using 'fhc'
> (Fred's Haskell Compiler) will we still have this reference to
> 'split-base' in our cabal files? how many more flags will have
> accumulated by then? Sure it's declarative, but in a language that
> doesn't make sense without the rule-book.  autoconf tests things like
> 'does a library named foo exist and export bar'. 'is char signed or
> unsigned on the target system'. those are declarative statement and
> have a defined meaning through all time. (though, implemented in a
> pretty ugly imperative way) That is what allows autoconfed packages to
> be compiled by compilers on systems that were never dreamed of when the
> packages were written.

The important thing about Cabal's way of specifying dependencies is that
(Continue reading)

Permalink | Reply |
headers
Simon Peyton-Jones | 28 Aug 16:02

RE: Build system idea

| 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 available
| *as data* gave us a lot more scope for automation, albeit at the expense of
| some generality.

Now there's a useful insight for the paper I hope Duncan (or someone) is going to write

        configuration as code [autoconf]
vs
        configuration as data [cabal]

Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply |
headers
Sterling Clover | 29 Aug 04:00

Re: Build system idea

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 room for a fruitful middle ground. Thanks  
to Hackage, at least for those packages that build properly and  
haddock on it, we have, although not in the best format, information  
on the type signatures of the functions of packages, across various  
package versions. So if I, when writing a cabal script, don't  
particularly want to figure out the exact range of, e.g., Network,  
packages that provide the correct API, it would be fairly reasonable  
to statically determine which functions from the Network package that  
are called, and which versions of Network on hackage provide them,  
and with the appropriate types no less. Thus, given that we need  
"Network," a tool could determine what the correct allowable range of  
versions is, and thus avoid both over- and under- specification.

This same tool could be run over existing .cabal files on hackage,  
statically determining when they are likely to either over- or under-  
specify, and alerting package maintainers to this.

--Sterl.

On Aug 28, 2008, at 10:02 AM, 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
(Continue reading)

Permalink | Reply |
headers
Brandon S. Allbery KF8NH | 29 Aug 04:21
Favicon

Re: Build system idea

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 .hi files (and indeed ghc will  
dump it for you:  ghc --dump-iface foo.hi).  In theory there could be  
a master dictionary of these hosted on hackage, collected from each  
package's own dictionary, and a given package's dependencies could be  
computed with high accuracy from it.

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH
Permalink | Reply |
headers
Simon Marlow | 29 Aug 10:37

Re: Build system idea

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 to extract the information from .hi files (and indeed ghc will dump 
> it for you:  ghc --dump-iface foo.hi).  In theory there could be a 
> master dictionary of these hosted on hackage, collected from each 
> package's own dictionary, and a given package's dependencies could be 
> computed with high accuracy from it.

It's a good idea, but conditional compilation makes it quite a bit harder.

Cheers,
	Simon
Permalink | Reply |
headers
Duncan Coutts | 3 Sep 02:22
Gravatar

RE: Build system idea

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, but then we realised that having the package configuration available
> | *as data* gave us a lot more scope for automation, albeit at the expense of
> | some generality.
> 
> Now there's a useful insight for the paper I hope Duncan (or someone) is going to write
> 
>         configuration as code [autoconf]
> vs
>         configuration as data [cabal]

and there are more fine distinctions even than that. Each change in the
power of the language used for configuration changes the range of things
that the developer and packager/user can do, and in opposite directions.
It's fairly similar to the tradeoffs between deep and shalow embeddings,
but I think we more intermediate points. The challenge is in
characterising the relationship between the language and the things the
developer and packager can do so that we can pick a useful point (or
points) in that tradeoff.

Before anyone thinks about writing a paper on this topic, I recommend
you read all of Eelco's papers[1] first just to make sure he's not
already done it! :-) Which is another point that there's lots that Cabal
(and ghc) can learn from Nix and related stuff.

Duncan
(Continue reading)

Permalink | Reply |
headers
Roman Leshchinskiy | 28 Aug 17:19
Favicon

Re: Build system idea

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 present then my  
> package will build.  ("but but but..." I hear you say - don't touch  
> that keyboard yet!)
>
> Suppose you used autoconf tests instead.  You might happen to know  
> that Network.Socket.blah was added at some point and write a test  
> for that, but alas if you didn't also write a test for  
> Network.Socket.foo (which your code uses but ends up getting removed  
> in network-1.1) then your code breaks.  Autoconf doesn't help you  
> make your configuration sound, and you get no prior guarantee that  
> your code will build.

Cabal doesn't give this guarantee, either, since it allows you to  
depend on just network or on network>x. To be perfectly honest, I  
think neither autoconf's approach (free-form feature tests) nor  
Cabal's (version-based dependencies) really work for all important use  
cases. And I have to disagree with what you write below - I think both  
systems are fundamentally flawed.

As I said before, what does (mostly) work IMO is depending on  
interfaces which are independent of packages. Being required to  
specify the exact interface you depend on solves the problem you  
describe above. It also solves the problem of name clashes with  
functions defined in later versions of a package. And it is still  
nicely declarative.
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 28 Aug 17:31

Re: Build system idea

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 as those dependencies are present then my package will 
>> build.  ("but but but..." I hear you say - don't touch that keyboard 
>> yet!)
>>
>> Suppose you used autoconf tests instead.  You might happen to know 
>> that Network.Socket.blah was added at some point and write a test for 
>> that, but alas if you didn't also write a test for Network.Socket.foo 
>> (which your code uses but ends up getting removed in network-1.1) then 
>> your code breaks.  Autoconf doesn't help you make your configuration 
>> sound, and you get no prior guarantee that your code will build.
> 
> Cabal doesn't give this guarantee, either, since it allows you to depend 
> on just network or on network>x.

Indeed.  That's why I was careful not to say that Cabal gives you the 
guarantee, only that it's easy to achieve it.

>> Both systems are flawed, but neither fundamentally.  For Cabal I think 
>> it would be interesting to look into using more precise dependencies 
>> (module.identifier::type, rather than package-version) and have them 
>> auto-generated.  But this has difficult implications: implementing 
>> cabal-install's installation plans becomes much harder, for example.
> 
> Interesting. From our previous discussion I got the impression that you
(Continue reading)

Permalink | Reply |
headers
Roman Leshchinskiy | 29 Aug 05:48
Favicon

Re: Build system idea

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 network==1.0, then I can  
>>> guarantee that as long as those dependencies are present then my  
>>> package will build.  ("but but but..." I hear you say - don't  
>>> touch that keyboard yet!)
>>>
>>> Suppose you used autoconf tests instead.  You might happen to know  
>>> that Network.Socket.blah was added at some point and write a test  
>>> for that, but alas if you didn't also write a test for  
>>> Network.Socket.foo (which your code uses but ends up getting  
>>> removed in network-1.1) then your code breaks.  Autoconf doesn't  
>>> help you make your configuration sound, and you get no prior  
>>> guarantee that your code will build.
>> Cabal doesn't give this guarantee, either, since it allows you to  
>> depend on just network or on network>x.
>
> Indeed.  That's why I was careful not to say that Cabal gives you  
> the guarantee, only that it's easy to achieve it.

True, it's easy to specify. But IIUC, if you do so you have to update  
your package whenever any of the packages you depend on changes even  
if that change doesn't affect you. This is a very high (if not  
prohibitive) cost and one which the autoconf model doesn't force on you.

>>> Both systems are flawed, but neither fundamentally.  For Cabal I
(Continue reading)

Permalink | Reply |
headers
John Meacham | 29 Aug 00:16
Favicon

Re: Build system idea

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 those dependencies are present then my package will build.  
> ("but but but..." I hear you say - don't touch that keyboard yet!)

I can easily achieve this with autoconf or even nothing, I can simply do
a test to see if a system is running fedora core 9 using ghc 6.8.2 and
be assured that my package will build properly. But this misses the
entire point, I want my package to build not on my exact system, I want
it to build on _other_ peoples systems. People running with compilers and
libraries and on operating systems I never heard of.

However, this has the huge flaw of requiring a closed universe. A
complete and universal definition of what 'network == 1.0' means for all
time that all future compilers must agree on. It places a huge burden on
implementors to provide a 'network=1.0' compatible interface, simply so
cabal doesn't complain even though all programs would be happy with a
jhc-network 0.7 or a internet-5.0 package. It means that with
jhc-network which has 90% of the functionality of network, including
everything that 99.9% of all programs need every program will have to
either know about jhc-network to edit their cabal file to include it
conditionally, or they just won't work at all.

Note, this is similar to the problem of symbol versioning placed on
shared libraries. There is a fair amount of literature on the subject,
most unix's .so's used to have something similar to the current cabal model, a
version number with a minor/major part. it was found to lead to dll
hell. (well, .so hell) and we don't want to be in the place with haskell
(Continue reading)

Permalink | Reply |
headers
Ian Lynagh | 29 Aug 01:21
Gravatar

Re: Build system idea

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 support for that package.  There's no way to do generic 
> > autoconf->distro package generation, like there is with Cabal.
> 
> In cabal you only get it because you convinced the cabal people to put
> in code to support your distro. Which isn't much different than asking
> the package manager too.

I don't understand this. Cabal doesn't have any distro-specific code.

> And besides, this ability has nothing to do with cabal's configuration
> management capabilities, simply its metadata format.

I don't understand this either.

You imply you like Cabal's metadata, which says "I depend on network
version 1", right?

But you don't like Cabal's configuration management? What is Cabal's
configuration management, then?

> and there are many automatic package managers for autoconf style
> packages.
> 
> http://encap.org/ - one I use on pretty much all my systems. since it is
> distro independent.
(Continue reading)

Permalink | Reply |
headers
John Meacham | 29 Aug 01:53
Favicon

Re: Build system idea

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? What is Cabal's
> configuration management, then?

the build-depends field mainly, pretty much everything dealing with cabal
building a package rather than just describing the _result_ of a
successful building. 

One is constant between build systems and would be generally useful to
standardize independently, the other depends on the specific build
system/configuration manager used.

        John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈
Permalink | Reply |
headers
Simon Marlow | 29 Aug 10:37

Re: Build system idea

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 
>> as long as those dependencies are present then my package will build.  
>> ("but but but..." I hear you say - don't touch that keyboard yet!)
> 
> I can easily achieve this with autoconf or even nothing, I can simply do
> a test to see if a system is running fedora core 9 using ghc 6.8.2 and
> be assured that my package will build properly. But this misses the
> entire point, I want my package to build not on my exact system, I want
> it to build on _other_ peoples systems. People running with compilers and
> libraries and on operating systems I never heard of.

But you can only do that by carefully enumerating all the dependencies of 
your code.  autoconf doesn't help you do that - you end up underspecifying 
the dependencies.  Cabal makes you overspecify.  It's a 
soundness/completeness thing: Cabal is sound(*1), autoconf is complete(*2). 
  You complain that Cabal is incomplete and I complain that autoconf is 
unsound.  I'd like to make Cabal's dependency specs more complete, but I 
don't want to make it unsound.

(*1) as long as you specify dependencies with both upper and lower bounds
(*2) as long as you don't overspecify dependencies

I'd be interested in discussing how to improve Cabal's dependency 
specifications, if you have any thoughts on that.

> Again, I would like to see this as another option. I think there are
(Continue reading)

Permalink | Reply |
headers
Iavor Diatchki | 4 Sep 18:59

Re: Build system idea

Hi,

On Thu, Aug 28, 2008 at 6:59 AM, Simon Marlow <marlowsd <at> gmail.com> 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 than a
> screenful, so it's no big deal to switch to something else later if you need
> to.

Well, I think this illustrates the current thinking of the Haskell
community, where emphasis has been on making things either easy to do,
or really hard/impossible to do (a kind of Mac approach to software
development! :-).  It has the benefit that it makes things seem really
easy occasionally, but is it really honest?  Concretely:

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.

Haddock:  something seems wrong, if I need to use a specific build
system to document my code!

source distributions:  cabal is really of very little help here as one
has to enumerate everything that should be in the distribution.

Hackage:  Again, something is wrong if I should have to use a specific
build system to distribute my code.

distro-packages: I have not used these, but the only ones that I have
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 4 Sep 22:30
Gravatar

Re: Build system idea

On Thu, 2008-09-04 at 09:59 -0700, Iavor Diatchki wrote:
> Hi,
> 
> On Thu, Aug 28, 2008 at 6:59 AM, Simon Marlow <marlowsd <at> gmail.com> 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 than a
> > screenful, so it's no big deal to switch to something else later if you need
> > to.
> 
> Well, I think this illustrates the current thinking of the Haskell
> community, where emphasis has been on making things either easy to do,
> or really hard/impossible to do (a kind of Mac approach to software
> development! :-).  It has the benefit that it makes things seem really
> easy occasionally, but is it really honest?  Concretely:
> 
> 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 different flags
so I don't think that's right. Under that assumption cabal-install can
in principle resolve everything fine. I'm not claiming the current
resolution algorithm is very clever when it comes to picking flags
(though it should always pick ones that give an overall valid solution)
but there is certainly scope for a cleverer one. Also, the user can
always specify what features they want, which is what systems like
Gentoo do.
(Continue reading)

Permalink | Reply |
headers
Sean Leather | 5 Sep 01:08

Re: Build system idea


> 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 different flags
so I don't think that's right. Under that assumption cabal-install can
in principle resolve everything fine. I'm not claiming the current
resolution algorithm is very clever when it comes to picking flags
(though it should always pick ones that give an overall valid solution)
but there is certainly scope for a cleverer one. Also, the user can
always specify what features they want, which is what systems like
Gentoo do.

Do you have any specific test cases where the current algorithm is less
than ideal? It'd be useful to report those for the next time someone
hacks on the resolver.

I have a package that builds a library and a test executable. The test executable uses QuickCheck 2, but I don't want to force random Jane who cabal-installs my package to install QuickCheck 2. One, it's not packaged up, and two, it's not necessary for using the library. The cleanest way I found to deal with this is to use a flag for hiding the build-depends of the test executable for the flag-less build.

if flag(test)
  build-depends: QuickCheck >= 2.0
else
  buildable: False

Sean
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply |
headers
Iavor Diatchki | 5 Sep 08:15

Re: Build system idea

Hello,

On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
<duncan.coutts <at> worc.ox.ac.uk> 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
>> cabal file.
>
> Packages are not supposed to expose different APIs with different flags
> so I don't think that's right. Under that assumption cabal-install can
> in principle resolve everything fine. I'm not claiming the current
> resolution algorithm is very clever when it comes to picking flags
> (though it should always pick ones that give an overall valid solution)
> but there is certainly scope for a cleverer one. Also, the user can
> always specify what features they want, which is what systems like
> Gentoo do.
>
> Do you have any specific test cases where the current algorithm is less
> than ideal? It'd be useful to report those for the next time someone
> hacks on the resolver.

The examples that I was thinking of arise when libraries can provide
conditional functionality, depending on what is already installed on
the system, a kind of "co-dependecy".  For a concrete example, take a
look at the JSON library that I wrote (I think that it is on hackage).
 It provides a number of different modules containing parsers written
with different parser combinators: one that does not use a library,
one that uses ReadP, and one that uses Parsec. The idea was that we do
not want to force people to install a particular parser combinator
library, instead, we provide compatibility with many different ones.
Certainly, JSON does not require _all_ libraries to be installed, but
the way the flags are at the moment, I think that that is what happens
if you just use cabal-install.  (The same sort of thing happens when a
library provides instances for datatypes defined in different
packages---these instances are often not required by the library, but
are useful _if you have the other package installed_.)

I guess, you could say that we structured the library wrong---perhaps
we should have had a core package that only provides manual parsing
(no external libraries required), and then have a separate packages
for each of the parsers that use a different parsing combinator
library.

Conceptually, this might be better, but in practice it seems like a
bit of a pain---each parser is a single module, but it would need a
whole separate directory, with a separate cabal file, license, and a
setup script, all of which would be almost copies of each other.
Similarly, in the case of providing instances for datatypes from
different packages, one would end up with a separate package for each
set of instances, which would result in a proliferation of tiny
packages.  It seems that this problem should be solvable though... :-)

(by the way, this has little to do with the GHC build system, so
perhaps we should start a separate thread?)

-Iavor
Permalink | Reply |
headers
Sittampalam, Ganesh | 28 Aug 09:29
Favicon

RE: Build system idea

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

> > that we can automatically generate distro packages for hundreds of 
> > packages is not insignificant. This is just not possible with the 
> > autoconf approach.

> This is just utterly untrue. autoconfed packages that generate rpms, 
> debs, etc are quite common.

Can you give an example of how this works? I would expect autoconf
scripts to be completely missing the necessary metadata to do this.

> As for programs written in haskell, I don't want people's first
> impression of haskell being "oh crap, I gotta learn a new way to
> build things just because this program is written in some odd language
> called 'haskell'" I don't care how awesome a language is, I am going
> to be annoyed by having to deal with it when I just want to
> compile/install a program. It will leave a bad taste in my mouth.
> I would much rather peoples first impression be "oh wow, this
> program is pretty sweet. I wonder what it is written in?" hence
> they all use ./configure && make by design rather than necessity.

On the flip side, ./configure && make is completely useless on
native windows (i.e. without cygwin, mingw or the like) platforms,
whereas cabal works everywhere GHC does.

Cheers,

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
Permalink | Reply |
headers
Simon Peyton-Jones | 28 Aug 11:27

RE: Build system idea

| 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 we
| can automatically generate distro packages for hundreds of packages is
| not insignificant. This is just not possible with the autoconf approach.
...
| Do you think that separating the Simple build system from the
| declarative part of Cabal would help? It'd make it more obvious that the
| build system part really is replaceable which currently is not so
| obvious since they're in the same package. I'm not averse to splitting
| them if it'd help. They're already completely partitioned internally.


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 internally".

These things are clear to you, but my sense it that they are *not* clear even to other well-informed people. 
(I exclude myself from this group.)  It's like the Loch Ness monster: the bits above the waves make sense
only when you get an underwater picture that shows you the monster underneath that explains why the humps
surface in the way they do.

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 the Cabal viewpoint, contrasts with alternatives, and thereby allows
discussion about Cabal to be better informed.

Simon


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 using the declarative part but not the build-system part.


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply |
headers
Brandon S. Allbery KF8NH | 28 Aug 16:02
Favicon

Re: Build system idea

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 the Cabal viewpoint,  
> contrasts with alternatives, and thereby allows discussion about  
> Cabal to be better informed.

I think we're at the point where such a document is necessary if we're  
going to have a coherent discussion.  (And as an aside, I think the  
same is true of darcs.)

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH
Permalink | Reply |
headers
Roman Leshchinskiy | 28 Aug 16:55
Favicon

Re: Build system idea

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 internally".
>
> These things are clear to you, but my sense it that they are *not*  
> clear even to other well-informed people.  (I exclude myself from  
> this group.)  It's like the Loch Ness monster: the bits above the  
> waves make sense only when you get an underwater picture that shows  
> you the monster underneath that explains why the humps surface in  
> the way they do.

FWIW, I fully agree with this (although I'm not especially well- 
informed in this particular area). It would be immensely helpful if  
Cabal's "philosophy" was described somewhere.

Roman