building haddock?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

building haddock?

Malcolm Wallace
Quick question:  how do I build Haddock from the darcs repo?

Long version:

Using Cabal as provided with ghc-6.4.1 gave me this error:
    $ ghc-6.4.1 --make Setup
    $ ./a.out configure --help
    a.out: Line 12: Unknown field 'data-files'

So I tried to upgrade Cabal to a newer version.  Following the
instructions to the letter, there was some weirdness with compiler
versions, but I did end up with a newer Cabal:

    $ cd cabal-1.1.3
    $ ghc-pkg-6.4.1 unregister Cabal
    Saving old package config file... done.
    Writing new package config file... done.
    $ vi GNUMakefile # edit HC=ghc-6.4.1, HC_PKG=ghc-pkg-6.4.1
    $ make install
    mkdir -p dist/tmp
    ghc-6.4.1 --make -Wall -fno-warn-unused-matches -cpp -i.
         -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup
    ...
    ./setup configure --ghc --prefix=/usr/malcolm/local
    Configuring Cabal-1.1.3...
    configure: Using install prefix: /usr/malcolm/local
    configure: Using compiler: /grp/haskell/bin/ghc
                                                # this is wrong
    configure: Compiler flavor: GHC
    configure: Compiler version: 6.2.2 # eek! this is wrong
    configure: Using package tool: /grp/haskell/bin/ghc-pkg
                                                # this is wrong too
    ...
    ./setup install
    Installing: /usr/malcolm/local/lib/Cabal-1.1.3/ghc-6.2.2
                 & /usr/malcolm/local/bin Cabal-1.1.3...
                                # installed for wrong compiler
    Registering Cabal-1.1.3...
    Reading package info from ".installed-pkg-config"done.
    Expanding embedded variables... done.
    Saving old package config file... done.
    Writing new package config file... done.

    # Cabal is missing from ghc-6.4.1
    $ ghc-pkg-6.4.1 -l
      /usr/malcolm/local/lib/ghc-6.4.1/package.conf:
        rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0,
        parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0,
        HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, OpenGL-2.0,
        GLUT-2.0, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0),
        (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0),
        (hssource-1.0)
    # ...but is installed for ghc-6.2.2
    $ ghc-pkg-6.2.2 -l
      /grp/haskell/lib/ghc-6.2.2/package.conf:
        rts, base, haskell98, haskell-src, network, parsec, QuickCheck,
        readline, unix, lang, concurrent, posix, util, data, text, net,
        hssource, hat, HaXml, wxcore, wx, Cabal

But the killer is, it still doesn't work:

    $ cd haddock
    $ ghc-6.2.2 --make Setup -package Cabal
    Chasing modules from: Setup
    Compiling Main             ( Setup.lhs, Setup.o )
    Linking ...
    $ ./a.out t configure --help
    a.out: haddock.cabal:12: Unknown field 'data-files'


So then I tried just building haddock directly with ghc:

    $ ghc-6.4 --make Main.hs
    Chasing modules from: Main.hs
    Main.hs:39:1: lexical error
    $ ghc-6.4 --make -cpp Main.hs
    Chasing modules from: Main.hs
    Could not find module `Paths_Haddock':
      use -v to see a list of the files searched for
      (imported from Main.hs)

And now I'm stuck.  There genuinely is no module called Paths_Haddock.

Regards,
    Malcolm
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: building haddock?

Duncan Coutts
On Tue, 2006-01-31 at 12:17 +0000, Malcolm Wallace wrote:
> Quick question:  how do I build Haddock from the darcs repo?

You need a later version of Cabal. Later than 1.1.3.

>     Could not find module `Paths_Haddock':
>       use -v to see a list of the files searched for
>       (imported from Main.hs)
>
> And now I'm stuck.  There genuinely is no module called Paths_Haddock.

This module is generated by Cabal. But not in Cabal 1.1.3, a later
version.


We really need a field:

cabal-depends: 1.1.4

So that older versions of Cabal can say "you need version
${cabal-depends} of Cabal to build this package".

Duncan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: building haddock?

Malcolm Wallace
Duncan Coutts <[hidden email]> writes:

> > Quick question:  how do I build Haddock from the darcs repo?
>
> You need a later version of Cabal. Later than 1.1.3.

Just to be clear, this can only mean the Cabal darcs repo, yes?
I couldn't find a release candidate newer than 1.1.3 on the main
Cabal webpage:

    http://haskell.org/cabal

Regards,
    Malcolm
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: building haddock?

Simon Marlow-5
In reply to this post by Duncan Coutts
Duncan Coutts wrote:

> On Tue, 2006-01-31 at 12:17 +0000, Malcolm Wallace wrote:
>
>>Quick question:  how do I build Haddock from the darcs repo?
>
>
> You need a later version of Cabal. Later than 1.1.3.
>
>
>>    Could not find module `Paths_Haddock':
>>      use -v to see a list of the files searched for
>>      (imported from Main.hs)
>>
>>And now I'm stuck.  There genuinely is no module called Paths_Haddock.
>
>
> This module is generated by Cabal. But not in Cabal 1.1.3, a later
> version.
>
>
> We really need a field:
>
> cabal-depends: 1.1.4
>
> So that older versions of Cabal can say "you need version
> ${cabal-depends} of Cabal to build this package".

There is such a field:

   cabal-version: >=1.1.4

but I didn't use it in Haddock (now fixed).  This field doesn't help
with all the backwards compatibility issues, particularly API changes in
the Cabal libraries, as we know (see previous discussions).

Cheers,
        Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: building haddock?

Duncan Coutts
On Tue, 2006-01-31 at 13:54 +0000, Simon Marlow wrote:
> Duncan Coutts wrote:

> > We really need a field:
> >
> > cabal-depends: 1.1.4
> >
> > So that older versions of Cabal can say "you need version
> > ${cabal-depends} of Cabal to build this package".
>
> There is such a field:
>
>    cabal-version: >=1.1.4

Really! I had never seen it.

> but I didn't use it in Haddock (now fixed).  This field doesn't help
> with all the backwards compatibility issues, particularly API changes in
> the Cabal libraries, as we know (see previous discussions).

Indeed, because by the time the cabal Setup.lhs reads the file it's too
late. Hence my suggestion in the previous discussions for a cabal
program that reads the file, decides which version of the Cabal libs to
use and then builds a setup program and passes control on to that.

Duncan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: building haddock?

Isaac Jones-2
Duncan Coutts <[hidden email]> writes:

> On Tue, 2006-01-31 at 13:54 +0000, Simon Marlow wrote:
>> Duncan Coutts wrote:
>
>> > We really need a field:
>> >
>> > cabal-depends: 1.1.4
>> >
>> > So that older versions of Cabal can say "you need version
>> > ${cabal-depends} of Cabal to build this package".
>>
>> There is such a field:
>>
>>    cabal-version: >=1.1.4
>
> Really! I had never seen it.
>
>> but I didn't use it in Haddock (now fixed).  This field doesn't help
>> with all the backwards compatibility issues, particularly API changes in
>> the Cabal libraries, as we know (see previous discussions).
>
> Indeed, because by the time the cabal Setup.lhs reads the file it's too
> late. Hence my suggestion in the previous discussions for a cabal
> program that reads the file, decides which version of the Cabal libs to
> use and then builds a setup program and passes control on to that.

Ahem. Cabal-install.

It doesn't read that field yet, though.

peace,

  isaac
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: building haddock?

Simon Marlow
In reply to this post by Malcolm Wallace
On 31 January 2006 21:38, Isaac Jones wrote:

> Duncan Coutts <[hidden email]> writes:
>
>> On Tue, 2006-01-31 at 13:54 +0000, Simon Marlow wrote:
>>> Duncan Coutts wrote:
>>
>>>> We really need a field:
>>>>
>>>> cabal-depends: 1.1.4
>>>>
>>>> So that older versions of Cabal can say "you need version
>>>> ${cabal-depends} of Cabal to build this package".
>>>
>>> There is such a field:
>>>
>>>    cabal-version: >=1.1.4
>>
>> Really! I had never seen it.
>>
>>> but I didn't use it in Haddock (now fixed).  This field doesn't help
>>> with all the backwards compatibility issues, particularly API
>>> changes in the Cabal libraries, as we know (see previous
>>> discussions).
>>
>> Indeed, because by the time the cabal Setup.lhs reads the file it's
>> too late. Hence my suggestion in the previous discussions for a cabal
>> program that reads the file, decides which version of the Cabal libs
>> to use and then builds a setup program and passes control on to that.
>
> Ahem. Cabal-install.
>
> It doesn't read that field yet, though.

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.

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.

Cheers,
        Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: building haddock?

Isaac Jones-2
"Simon Marlow" <[hidden email]> writes:

> On 31 January 2006 21:38, Isaac Jones wrote:
(snip)
>> Ahem. Cabal-install.
>>
>> It doesn't read that field yet, though.
>
> 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 :)

> 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?

The problems with the setup script are mainly:
 1) the interface changes (though that is hopefully a short-term problem)
 2) we can't count on runhaskell being installed

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.

peace,

  isaac

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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⑈
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

cabal setup scripts (was: Re: building haddock?)

Isaac Jones-2
John Meacham <[hidden email]> writes:

> 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)

I do understand your position as you state it, that you think the
Setup scripts cause unnecessary complexity.  I think they serve an
important purpose that I hope I can explain to you.  Maybe you could
capture our two arguments on a wiki page somewhere :)

> we should add a field to the cabal file:
>
> build-style: simple
> build-style: make

I am coming around to a certain amount of what you say.  I'm leaning
toward a scheme something like "if the setup script is there, build it
and use it, otherwise use defaultMain."  Let's call that the "optional
Setup" proposal.  This has always been on the table, BTW, and the
reason that I resist it is because it's much harder to _add_ a
requirement of a setup script than to relax it.

The optional Setup proposal helps us get rid of the difficulty of
compiling the Setup script (for "simple" systems) in exchange for the
difficulty of distributing cabal-install.

In fact, distributing runhaskell would basically have the same effect.

I think that if we drop the requirement for the Setup scripts, then
we'll probably want a build-style field, but I think the values should
probably be "simple" and "setup"; maybe "make" and something to
represent "main=defaultMainWithHooks defaultUserHooks".

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

You lose me here, I feel like this idea gives up most of the pros we
gained by dropping the Setup script.

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

So the build hooks basically all become IO ()?  That's rather
unsatisfying to me as a functional programmer :)

(snip)

> <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>

While we're talking philosophy maybe I can let you in on the
philosophy behind the Setup script.  One problem with domain-specific
declarative languages like the .cabal file is that they grow into
(ugly) turing complete programming languages.  I would prefer to keep
cabal rather simple (it's already almost too complex, IMO) and yes,
push the complexity into the setup script.  You may see it as passing
the buck, I see it as allowing the end user to program in a beautiful
language for those inevitable turing-tasks.

Cabal can and should leverage abstraction where it appears, such as
preprocessors and Programs (which it can detect and add nice flags
like --with-foo-path= and --with-foo-args=).

You did seem to recognize the necessity for escaping to a
turing-complete language in your build-style: custom proposal.
Indeed, your proposal requires us to bail out to a turing complete
language in exactly the same circumstances as the current situation.


peace,

  isaac
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: cabal setup scripts (was: Re: building haddock?)

John Meacham
On Wed, Feb 01, 2006 at 08:52:16PM -0800, Isaac Jones wrote:

> I think that if we drop the requirement for the Setup scripts, then
> we'll probably want a build-style field, but I think the values should
> probably be "simple" and "setup"; maybe "make" and something to
> represent "main=defaultMainWithHooks defaultUserHooks".
>
> > build-style: custom runhaskell Setup.lhs
> > build-style: custom runhaskell MyBuild.hs -c %
>
> You lose me here, I feel like this idea gives up most of the pros we
> gained by dropping the Setup script.

it is because a user might want to use something other than runhaskell
Setup.hs (which appears to be what you mean by the 'setup' option) as
their custom build system.

build-style: setup
would be equivalent to
build-style: custom runhaskell Setup.hs

for backwards compatability cabal files without a build-style field
would be interpreted as build-style: setup

I never wanted to disallow Setup.hs, but it should not be the required
way to do things.

> > 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.
>
> So the build hooks basically all become IO ()?  That's rather
> unsatisfying to me as a functional programmer :)

arn't a lot of them IO ExitCode anyway? that is because we probably
expect a lot of them to just be System.system "foo".

it seems like a very natural thing to add. like I said, the library
exists, but for something as simple as hooks that just call programs, it
should not be needed when cabal-install can take care of it.

> While we're talking philosophy maybe I can let you in on the
> philosophy behind the Setup script.  One problem with domain-specific
> declarative languages like the .cabal file is that they grow into
> (ugly) turing complete programming languages.  I would prefer to keep
> cabal rather simple (it's already almost too complex, IMO) and yes,
> push the complexity into the setup script.  You may see it as passing
> the buck, I see it as allowing the end user to program in a beautiful
> language for those inevitable turing-tasks.

it is forcing them to. which is bad. no matter how beautiful haskell is.
Quadruply especially so since it does not gain you anything. since it is
not needed.

I don't see cabal files becoming anywhere near turing complete. then it
wouldn't be declarative (at least in the sense I mean). at most, string
interpolation will be the only operation on its fields.

I am actually trying to simplify cabal a lot with these changes. a
program is hugely simpler than a library. Just from a maintenence point
of view, must of the issues dealing with syncing cabal and ghc releases,
cabal library version changes, etc would just have never been issues.
what about multiple compilers and keeping your cabal installs in sync
among all of them? it is just a big mess.

not to mention how much simpler cabal development will be once it is
decoupled from the compiler libraries and can evolve independently.

> You did seem to recognize the necessity for escaping to a
> turing-complete language in your build-style: custom proposal.
> Indeed, your proposal requires us to bail out to a turing complete
> language in exactly the same circumstances as the current situation.

no, in the current situation you have no _choice_ but to bail out into a
turing complete langauge. which will promptly be used to get back into a
standard library most of the time which has already been linked into the
executable that bailed you into the turing language to begin with. it
really seems silly. especially when there are so many pitfalls. I really
don't see how it can be considered a good idea to force a users hand
when you don't have to, and can simplify things in the process.

at least with a build-style: option then meta-tools can look and
imediatly know which packages it needs to handle specially. you don't
even have that option if everything is _required_ to use a program. A
program that can modify arbitrary things at that. want to build the
program as a user and then just do the install as root? well you are
going to be running arbitrary user code as root since you need to to do
a runhaskell Setup.hs install. rather than having to audit every program
you install, you just need to look at the ones with install-hooks.

Easy things easy and hard things possible. making cabal a library
definitly makes easy things possible, but certainly not easy.

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: cabal setup scripts (was: Re: building haddock?)

Aaron Denney
On 2006-02-02, John Meacham <[hidden email]> wrote:

> it is forcing them to. which is bad. no matter how beautiful haskell is.
> Quadruply especially so since it does not gain you anything. since it is
> not needed.
>
> I don't see cabal files becoming anywhere near turing complete. then it
> wouldn't be declarative (at least in the sense I mean). at most, string
> interpolation will be the only operation on its fields.
>
> I am actually trying to simplify cabal a lot with these changes. a
> program is hugely simpler than a library. Just from a maintenence point
> of view, must of the issues dealing with syncing cabal and ghc releases,
> cabal library version changes, etc would just have never been issues.
> what about multiple compilers and keeping your cabal installs in sync
> among all of them? it is just a big mess.
>
> not to mention how much simpler cabal development will be once it is
> decoupled from the compiler libraries and can evolve independently.

I don't have much too add beyond "this is exactly how I think of the
issue, and why the whole point of cabal has seemed wrong up to now."
Thank you for articulating this.

--
Aaron Denney
-><-

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: building haddock?

Simon Marlow
In reply to this post by Malcolm Wallace
On 01 February 2006 17:45, Isaac Jones wrote:

> "Simon Marlow" <[hidden email]> writes:
>
>> On 31 January 2006 21:38, Isaac Jones wrote:
> (snip)
>>> Ahem. Cabal-install.
>>>
>>> It doesn't read that field yet, though.
>>
>> 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 :)
>
>> 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'm referring to discussion from a couple of weeks ago:

  http://www.haskell.org//pipermail/libraries/2006-January/004815.html

basically, yes, I think Cabal should come with a tool that you run
instead of 'runhaskell Setup.hs'.

This will actually result in more consistency, because as Duncan pointed
out in that thread, there are currently lots of ways to run Setup.hs.

The tool can check for the cabal-version field before it does anything,
and run the Setup script with the appropriate version of Cabal (or fail
if it can't find it).  This neatly fixes the problem of changing APIs in
Cabal.

The command line interface for the tool can be exactly the same as Setup
right now.  Plus another option to behave like cabal-install, maybe.

> The problems with the setup script are mainly:
>  1) the interface changes (though that is hopefully a short-term
>  problem) 2) we can't count on runhaskell being installed
>
> 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.

Stabilizing the API and layered tools are both good, but I'm sure we'll
want to extend the API in the future.  Using a small wrapper program
instead of invoking Setup.hs directly ensures we'll be able to do this
smoothly in the future, without breaking lots of Setup scripts.

I don't think this is that big a deal, it isn't a fundamental design
switch, the functionality is still implemented in Haskell and completely
customisable by each package, all we're doing is replacing the words
'runhaskell Setup.hs' with 'cabal-setup' (or something).

Cheers,
        Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: cabal setup scripts (was: Re: building haddock?)

Frederik Eaton-3
In reply to this post by Isaac Jones-2
I haven't been following this closely, but I think I have to agree
with Isaac on this point. To me it seems that the .cabal language is
already Turing complete in the sense that one can get it do anything
by writing to the Haskell mailing lists. That's neither efficient for
the users, nor for Isaac.

(However, I do think it would be much nicer if one could use say
"cabal-setup" or just "cabal" instead of "runhaskell Setup.hs"...)

> While we're talking philosophy maybe I can let you in on the
> philosophy behind the Setup script.  One problem with domain-specific
> declarative languages like the .cabal file is that they grow into
> (ugly) turing complete programming languages.  I would prefer to keep
> cabal rather simple (it's already almost too complex, IMO) and yes,
> push the complexity into the setup script.  You may see it as passing
> the buck, I see it as allowing the end user to program in a beautiful
> language for those inevitable turing-tasks.
>
> Cabal can and should leverage abstraction where it appears, such as
> preprocessors and Programs (which it can detect and add nice flags
> like --with-foo-path= and --with-foo-args=).
>
> You did seem to recognize the necessity for escaping to a
> turing-complete language in your build-style: custom proposal.
> Indeed, your proposal requires us to bail out to a turing complete
> language in exactly the same circumstances as the current situation.
>
>
> peace,
>
>   isaac
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries