building haddock?

[John Meacham]

On Wed, Feb 01, 2006 at 09:45:27AM -0800, Isaac Jones wrote:
> > Do you intend cabal-install to be the main interface to Cabal?  That's
> > what Duncan was proposing (and others have suggested) - that we
> > deprecate the use of 'runhaskell Setup.lhs' as the interface to Cabal in
> > favour of a program to do the same.
> 
> I don't know if cabal-install should be the main interface or not; I
> think it's worth experimenting with.  As far as I know, I'm the only
> one who's tried it :)

I very strongly feel that 'cabal-install' should be the main interface
to cabal. having Setup.[l]hs files leads to a lot of headache and
doesn't gain us anything. (note, I am not saying drop the library, just
the need for Setup.* scripts)

we should add a field to the cabal file:

build-style: simple
build-style: make
build-style: custom runhaskell Setup.lhs
build-style: custom runhaskell MyBuild.hs -c %

where custom will just run its value passing through arguments to it.
'%' should be filled in with the name of the current cabal file so it
need not be seperatly specified to your custom handler.

This makes the simple cases a whole lot easier and less brittle and
doesn't lose any functionality.

I would also add

build-prehook:
build-posthook:
...

to the cabal file and have cabal-install just fill in those fields in
the hook record with the values from the file.

> > Certainly there doesn't seem much point in having *both* cabal-install
> > and another wrapper, so clearly they should be the same thing.  I do
> > think this is the way to go, though.
> 
> You think we should move away from saying that "setup" is the
> interface?  Would we start distributing cabal-install w/ the
> compilers, or expect users to install it on their own?

I definitly think cabal-install should be an independent project on its
own. it should also come with the 'runhaskell' script that has the logic
currently in cabal-install to choose an appropriate runghc vs runhugs vs
runjhc as appropriate since that makes sense also as a compiler
independent project and distributing it with cabal-install seems like a
natural choice. (especially since the logic is already implemented in
there)

> A better solution might be to work hard on stabalizing the interface.
> I would like to try to stabalize cabal and move future development
> into layered tools.

these are laudable goals, but seem somewhat independent. We need a
working cabal-install now. we can easily start building better tools on
top of it then since for 90% of projects it will already be feature
complete.


<noise>

there is also a philosophical objection to Setup.hs as well as a practical
one. turing completeness is a one-way ratchet. once you decide on an
arbitrary program rather than having a declarative format then you lose
the ability to write meta-tools that analyze your projects in ways that
were originally unintended. a program is only good for its one task, you
can't look inside it, it is a black box. a declarative format can be
parsed and looked at in new and interesting ways. making things programs
should always be a last resort. Also, it is kind of passing the buck.
we avoid thinking about the hard problems by just saying 'write a custom
Setup.hs' to handle it. Of course, the joke is on us since we are the
ones using cabal so we are just passing the buck to ourselves. Also, it
feels a little embarasing that a functional language wouldn't use a
declarative format by default with a program as a last resort. 

</noise>

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈