cabal experiences

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

cabal experiences

Ian Lynagh

Hi all,

Here are the issues I ran into while cabalising some stuff recently.
It's possible that some of the problems are just me failing to find the
right option.

* No way to get extra files into the source tarball.

* No way to specify extra clean files.

* No way to specify extra object files to be put into a library.

* With "defaultMainWithHooks defaultUserHooks" clean is not removing
  config.log, config.status. Hmm, the dist/ directory doesn't seem to be
  being removed either.

* Again with "defaultMainWithHooks defaultUserHooks", sdist doesn't copy
  configure,

* "runghc6 Setup.hs sdist" without configuring tells me to run
  "setup configure", but wouldn't that restrict me to a particular compiler?
  (the same applies to clean, although it's not as critical there).

* I'm not sure why all cc-options can't be passed to hsc2hs with -C-optc
  (and likewise ld-options and -L-optl).

* I think -threaded should be an extension.


Thanks
Ian

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

Re: cabal experiences

Ross Paterson
On Sun, Dec 11, 2005 at 03:58:59PM +0000, Ian Lynagh wrote:
> Here are the issues I ran into while cabalising some stuff recently.
> It's possible that some of the problems are just me failing to find the
> right option.
>
> * No way to get extra files into the source tarball.
>
> * No way to specify extra clean files.

The CVS version (cf http://www.haskell.org/ghc/dist/current/docs/Cabal/)
has extra-source-files and extra-tmp-files fields, but I don't know if
they're in a release.

> * No way to specify extra object files to be put into a library.

How are those objects generated?

> * "runghc6 Setup.hs sdist" without configuring tells me to run
>   "setup configure", but wouldn't that restrict me to a particular compiler?
>   (the same applies to clean, although it's not as critical there).

The results of configure aren't used by sdist, though they are passed
(I don't know why).  Seems to be useless but harmless.

> * I'm not sure why all cc-options can't be passed to hsc2hs with -C-optc
>   (and likewise ld-options and -L-optl).

Some C compilers don't understand -optc and -optl.

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

Re: cabal experiences

Ian Lynagh
On Sun, Dec 11, 2005 at 04:37:54PM +0000, Ross Paterson wrote:

> On Sun, Dec 11, 2005 at 03:58:59PM +0000, Ian Lynagh wrote:
> > Here are the issues I ran into while cabalising some stuff recently.
> > It's possible that some of the problems are just me failing to find the
> > right option.
> >
> > * No way to get extra files into the source tarball.
> >
> > * No way to specify extra clean files.
>
> The CVS version (cf http://www.haskell.org/ghc/dist/current/docs/Cabal/)
> has extra-source-files and extra-tmp-files fields, but I don't know if
> they're in a release.

Oh, that reminds me of something else I meant to mention; personally I'd
rather see a ghc 6.6 release next rather than a 6.4.2 with a deficient
cabal again.

> > * No way to specify extra object files to be put into a library.
>
> How are those objects generated?

With a particularly ugly hack in my example, but a more reasonable case
would be stubs in a binding to a non-Haskell non-C library compiled in a
build hook (I think wxhaskell might be an example of this?).

> > * "runghc6 Setup.hs sdist" without configuring tells me to run
> >   "setup configure", but wouldn't that restrict me to a particular compiler?
> >   (the same applies to clean, although it's not as critical there).
>
> The results of configure aren't used by sdist, though they are passed
> (I don't know why).  Seems to be useless but harmless.

Even if configure doesn't affect sdist in any way, it would still be
much nicer not to require it is run IMO.

Come to think of it, this probably means you need to have the build-deps
etc satisfied to make a source distribution, which could be irritating.

> > * I'm not sure why all cc-options can't be passed to hsc2hs with -C-optc
> >   (and likewise ld-options and -L-optl).
>
> Some C compilers don't understand -optc and -optl.

Does hsc2hs ever use anything other than ghc (assuming you don't give it
-c)?

It would be nice if hsc2hs knew to add the -optc when given -C-foo and
using a ghc as the C compiler, though.


Thanks
Ian

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

Re: cabal experiences

Ross Paterson
On Sun, Dec 11, 2005 at 05:42:48PM +0000, Ian Lynagh wrote:
> Does hsc2hs ever use anything other than ghc (assuming you don't give it
> -c)?

If hsc2hs is run with Hugs, it defaults to using gcc.

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

Re: cabal experiences

Isaac Jones-2
In reply to this post by Ian Lynagh
Ian Lynagh <[hidden email]> writes:

> On Sun, Dec 11, 2005 at 04:37:54PM +0000, Ross Paterson wrote:
(snip)

>
>> > * "runghc6 Setup.hs sdist" without configuring tells me to run
>> >   "setup configure", but wouldn't that restrict me to a particular compiler?
>> >   (the same applies to clean, although it's not as critical there).
>>
>> The results of configure aren't used by sdist, though they are passed
>> (I don't know why).  Seems to be useless but harmless.
>
> Even if configure doesn't affect sdist in any way, it would still be
> much nicer not to require it is run IMO.

The same thing is true of ./setup clean.  That's ticket 12:
http://hackage.haskell.org/cgi-bin/trac/trac.cgi/ticket/12

> Come to think of it, this probably means you need to have the build-deps
> etc satisfied to make a source distribution, which could be irritating.

Thanks for pointing that out.

I'll make sure there are bug reports for each of the things you
brought up.

peace,

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

Re: cabal experiences

Tomasz Zielonka
In reply to this post by Ian Lynagh
On Sun, Dec 11, 2005 at 05:42:48PM +0000, Ian Lynagh wrote:
> Oh, that reminds me of something else I meant to mention; personally I'd
> rather see a ghc 6.6 release next rather than a 6.4.2 with a deficient
> cabal again.

I think I am not alone to want a bugfix 6.4.2 release. Otherwise we will
get 6.6 with bugs from 6.4.1 fixed, but with new bugs included.

PS. I am not criticising Simons - bugs are inevitable - that's what
    bugfix releases are for.

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

cabal release (was: cabal experiences)

Isaac Jones-2
In reply to this post by Ian Lynagh
Ian Lynagh <[hidden email]> writes:

> Oh, that reminds me of something else I meant to mention; personally I'd
> rather see a ghc 6.6 release next rather than a 6.4.2 with a deficient
> cabal again.

This reminds me, I'm actually thinking of trying for a cabal release
just after christmas (I'll have some free time).  This probably means
another relase candidate very soon, and an attempt at releasing 1.2
then.  1.2 might be a good version to get into ghc 6.6, though I
expect that it won't have configurations or shipments, since we won't
have much time to try those out. What's the schedule like for ghc 6.6?

Here are the open bugs on cabal that I've collected lately.  The ones
in the 1.2 milestone, marked "critical" are the ones I consider
"release-critical".  Unfortunitely, they're pretty vague, mostly it's
trying to decide what should get in the release:

http://hackage.haskell.org/cgi-bin/trac/trac.cgi/report/3

Lots of the other bugs are pretty easy.  Click on "Easy Tickets" here
to see stuff that's up for grabs :)

http://hackage.haskell.org/cgi-bin/trac/trac.cgi/wiki

peace,

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

RE: cabal release (was: cabal experiences)

Simon Peyton Jones

| then.  1.2 might be a good version to get into ghc 6.6, though I
| expect that it won't have configurations or shipments, since we won't
| have much time to try those out. What's the schedule like for ghc 6.6?

Well, the plan is for 6.6 to have impredicative types, and revised
GADTs. I'd like to fix the interaction of type classes and GADTs too.
And we'd like to have shaken down the parallel implementation a bit.  

The natural time for 6.6 feels like at least 3 months from now -- and
we'd rather not get pinned down to any dates for a while yet.  If the
reason you want 6.6 is to get a new Cabal, why not download a new Cabal
package?  Or is there another reason you want 6.6?

Bug-fixes to 6.4 are a much smaller deal.

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

RE: cabal release (was: cabal experiences)

Duncan Coutts
On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
> If the reason you want 6.6 is to get a new Cabal, why not download a
> new Cabal package?  Or is there another reason you want 6.6?

That is exactly the problem. All non-trivial packages need a later
version of Cabal since there are many many minor bug fixes and little
feature additions in later versions of Cabal.

So it's fine for package developers to download a later Cabal version
but the sense some people have is that they can't ask their users to
upgrade their Cabal installation from the one that comes with GHC.
 
> Bug-fixes to 6.4 are a much smaller deal.

The improvements are a mixture of bug fixes and feature additions and
some api changes. So because of the policy for minor versions of GHC is
to not change any apis including those of Cabal, GHC 6.4.1 came with a
version of Cabal that is widely acknowledged to be buggy and unsuitable
for many packages and distributors. We can sometimes persuade users to
upgrade their Cabal package separately from their GHC installation, but
not always.

In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. That is
after installing GHC 6.4.1 we unregister Cabal-1.0 and install
Cabal-1.1.3. We do not allow any choice in that. This was necessary
because our build/distribution infrastructure could not work around the
bugs in Cabal-1.0 and besides many packages that we want to distribute
require later versions of Cabal. So Gentoo users are ok, but other users
are not.

So this is why there is pressure in some quarters for a major release,
(6.6) rather than another minor release (6.4.2) since the former would
allow package authors to support a released version of GHC because it
would come with a usable version of Cabal. A minor release with the same
Cabal-1.0 would leave people in the same situation as now.

I appreciate that we do not want to rush the next major release because
there are new features that need to be got right. Perhaps we should
think again about which Cabal version to include in the next GHC minor
version, or perhaps to advise users in the release notes for GHC 6.4.2
that it is highly recommended to upgrade to Cabal version x.y.

Perhaps another compromise would be for GHC 6.4.2 to ship more than one
version of Cabal. It could ship version 1.0 and have that exposed by
default so that GHC's api stability guarantees could be met and it could
also ship a more recent version that we can agree upon so that it would
be much less difficult for the average user to build packages that
require more recent Cabal versions.

Duncan

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

RE: cabal release (was: cabal experiences)

Simon Peyton Jones
In reply to this post by Isaac Jones-2
Why is it easier to get users to upgrade from GHC 6.4.1 to GHC 6.6 than
it is to upgrade from Cabal 1.0 to Cabal 1.7 (say)?  I must be missing
something.

S

| -----Original Message-----
| From: [hidden email]
[mailto:[hidden email]] On Behalf Of Duncan
| Coutts
| Sent: 12 December 2005 15:14
| To: Simon Peyton-Jones
| Cc: [hidden email]; Isaac Jones
| Subject: RE: cabal release (was: cabal experiences)
|
| On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
| > If the reason you want 6.6 is to get a new Cabal, why not download a
| > new Cabal package?  Or is there another reason you want 6.6?
|
| That is exactly the problem. All non-trivial packages need a later
| version of Cabal since there are many many minor bug fixes and little
| feature additions in later versions of Cabal.
|
| So it's fine for package developers to download a later Cabal version
| but the sense some people have is that they can't ask their users to
| upgrade their Cabal installation from the one that comes with GHC.
|
| > Bug-fixes to 6.4 are a much smaller deal.
|
| The improvements are a mixture of bug fixes and feature additions and
| some api changes. So because of the policy for minor versions of GHC
is
| to not change any apis including those of Cabal, GHC 6.4.1 came with a
| version of Cabal that is widely acknowledged to be buggy and
unsuitable
| for many packages and distributors. We can sometimes persuade users to
| upgrade their Cabal package separately from their GHC installation,
but
| not always.
|
| In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. That
is
| after installing GHC 6.4.1 we unregister Cabal-1.0 and install
| Cabal-1.1.3. We do not allow any choice in that. This was necessary
| because our build/distribution infrastructure could not work around
the
| bugs in Cabal-1.0 and besides many packages that we want to distribute
| require later versions of Cabal. So Gentoo users are ok, but other
users
| are not.
|
| So this is why there is pressure in some quarters for a major release,
| (6.6) rather than another minor release (6.4.2) since the former would
| allow package authors to support a released version of GHC because it
| would come with a usable version of Cabal. A minor release with the
same
| Cabal-1.0 would leave people in the same situation as now.
|
| I appreciate that we do not want to rush the next major release
because
| there are new features that need to be got right. Perhaps we should
| think again about which Cabal version to include in the next GHC minor
| version, or perhaps to advise users in the release notes for GHC 6.4.2
| that it is highly recommended to upgrade to Cabal version x.y.
|
| Perhaps another compromise would be for GHC 6.4.2 to ship more than
one
| version of Cabal. It could ship version 1.0 and have that exposed by
| default so that GHC's api stability guarantees could be met and it
could
| also ship a more recent version that we can agree upon so that it
would
| be much less difficult for the average user to build packages that
| require more recent Cabal versions.
|
| Duncan
|
| _______________________________________________
| Libraries mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: cabal release (was: cabal experiences)

Duncan Coutts
On Mon, 2005-12-12 at 15:17 +0000, Simon Peyton-Jones wrote:
> Why is it easier to get users to upgrade from GHC 6.4.1 to GHC 6.6 than
> it is to upgrade from Cabal 1.0 to Cabal 1.7 (say)?  I must be missing
> something.

Because one appears to have "official" blessing and the other does not.

I know our department sysadmins would see it this way.

Crazy but true.

Duncan

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

Re: cabal release (was: cabal experiences)

Ian Lynagh
In reply to this post by Duncan Coutts
On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
>
> In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. That is
> after installing GHC 6.4.1 we unregister Cabal-1.0 and install
> Cabal-1.1.3.

If all distributions and users are going to have to do this to get a
usable system[1] then it seems obvious to me that ghc should already
come this way. That it doesn't causes headaches for packagers IME.

[1] "usable system" is a bit strong, but I hope you understand what I
    mean.

> I appreciate that we do not want to rush the next major release because
> there are new features that need to be got right. Perhaps we should
> think again about which Cabal version to include in the next GHC minor
> version, or perhaps to advise users in the release notes for GHC 6.4.2
> that it is highly recommended to upgrade to Cabal version x.y.

Incidentally, I would be happy if 6.4.2 was renamed 6.6 and newer cabal
added; I'm not asking for what is currently called 6.6 necessarily.

Or adding newer cabal to 6.4.2, against the policy, would suit me fine
too.


Thanks
Ian

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

RE: cabal release (was: cabal experiences)

Simon Marlow
In reply to this post by Isaac Jones-2
On 12 December 2005 15:31, Ian Lynagh wrote:

> On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
>>
>> In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1.
>> That is after installing GHC 6.4.1 we unregister Cabal-1.0 and
>> install Cabal-1.1.3.
>
> If all distributions and users are going to have to do this to get a
> usable system[1] then it seems obvious to me that ghc should already
> come this way. That it doesn't causes headaches for packagers IME.

I tend to agree.  I'm not against breaking the rules in this case, since
shipping Cabal-1.0 in 6.4.2 would be distinctly sub-optimal.  Shipping
two versions of Cabal is possible, but the build system isn't really set
up to do this, so it's non-trivial work, and it still requires the user
to say 'ghc-pkg expose Cabal-1.1.4; ghc-pkg hide Cabal-1.0'.

Cabal is something of a special case, because its use is pretty much
restricted to Setup.lhs scripts, which can be considered part of the
build system rather than the code of a library or application.  So this
is build system API breakage, not library API breakage, m'lud ;-)

I'd be rather happier if we could solve the versioning issue with Cabal,
so that upgrading Cabal in the future doesn't automatically break code.
It might not be possible to do this the first time around, but now is
the time to design our way out of future problems.

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

Re: cabal release (was: cabal experiences)

John Meacham
In reply to this post by Duncan Coutts
On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
> On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
> > If the reason you want 6.6 is to get a new Cabal, why not download a
> > new Cabal package?  Or is there another reason you want 6.6?
>
> That is exactly the problem. All non-trivial packages need a later
> version of Cabal since there are many many minor bug fixes and little
> feature additions in later versions of Cabal.

This is a large part of the reason I'd like to see cabal as a completly
separate package from any compiler with a programatic interface rather
than a library one. things will get very complicated when there are
multiple major compilers and you have to tell users things like 'run
runhaskell Setup.lhs, unless your runhaskell points to jhc, in which
case do runghc Setup.lhs, oh, create a link from runhaskell to your
proper compiler'.

We can do so without losing any flexability at all. just add a new line
to the cabal file

build-style: (makelike|simple|custom)

where makelike and simple just call the current cabal library routines
and custom lets you specify a command that should be run and arguments
passsed to it. (which can be something like 'runhaskell Setup.lhs')

seperating cabal into its own program would also be a good place to
provide a unified compiler independent 'runhaskell' script that can have
logic for finding and running an appropirate compiler so people don't
have to maintain an appropriate link to runhugs,runghc, or runjhc...


while having a source code interface makes a lot of sense for
single-source implementation-defined languages like perl, I think it is
very inappropriate for multi-source, compiled programs. Especially when
it gains you absolutly nothing other than headaches. The chance that
someone will have such an absurdly odd build setup that one of the
standard cabal models won't apply AND they can simulate the cabal
interface exactly are virtually nil and if such a thing does exist, a
build-style: custom will take care of it. You might not even have a
haskell compiler on the system you want to run cabal on.
(cross-compiling, bootstrapping)

        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 release (was: cabal experiences)

Simon Marlow
In reply to this post by Isaac Jones-2
On 13 December 2005 02:33, John Meacham wrote:

> On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
>> On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
>>> If the reason you want 6.6 is to get a new Cabal, why not download a
>>> new Cabal package?  Or is there another reason you want 6.6?
>>
>> That is exactly the problem. All non-trivial packages need a later
>> version of Cabal since there are many many minor bug fixes and little
>> feature additions in later versions of Cabal.
>
> This is a large part of the reason I'd like to see cabal as a
> completly separate package from any compiler with a programatic
> interface rather than a library one. things will get very complicated
> when there are multiple major compilers and you have to tell users
> things like 'run runhaskell Setup.lhs, unless your runhaskell points
> to jhc, in which case do runghc Setup.lhs, oh, create a link from
> runhaskell to your proper compiler'.
>
> We can do so without losing any flexability at all. just add a new
> line to the cabal file
>
> build-style: (makelike|simple|custom)
>
> where makelike and simple just call the current cabal library routines
> and custom lets you specify a command that should be run and arguments
> passsed to it. (which can be something like 'runhaskell Setup.lhs')

One usage of Setup.lhs that is becoming more common is to extend the
simple build system in small ways using hooks.  How do you envisage that
working with your scheme?  It looks like we would need to use "custom",
but we're back to needing a to provide the build system as a library,
otherwise every package needs to supply its own complete build system.
I don't immediately see how this solves the problem, but perhaps I'm
missing something.

I'm not against eliminating Setup.lhs in the (common) case when it is
just boilerplate.  But we need to retain the ability to customise the
simple build system, because it's both powerful and necessary.

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

Re: cabal release

Isaac Jones-2
In reply to this post by John Meacham
John Meacham <[hidden email]> writes:

> On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
>> On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
>> > If the reason you want 6.6 is to get a new Cabal, why not download a
>> > new Cabal package?  Or is there another reason you want 6.6?
>>
>> That is exactly the problem. All non-trivial packages need a later
>> version of Cabal since there are many many minor bug fixes and little
>> feature additions in later versions of Cabal.
>
> This is a large part of the reason I'd like to see cabal as a completly
> separate package from any compiler with a programatic interface rather
> than a library one. things will get very complicated when there are
> multiple major compilers and you have to tell users things like 'run
> runhaskell Setup.lhs, unless your runhaskell points to jhc, in which
> case do runghc Setup.lhs, oh, create a link from runhaskell to your
> proper compiler'.

To be fair, this isn't completely Cabal's fault.  Perl, Python, bash,
etc can all put #!/usr/bin/perl or whatever at the top of scripts.
For Haskell we're not there yet and the fact that we have multiple
major compilers is not really a good reason.

I propose that each haskell compiler / interpreter come with
runhaskell.  It should check to see whether runhaskell exists already
and if so, leave it alone.  If not, provide it.  That should probably
be tweakable with the configure script.

Whether Cabal comes w/ the compiler is invoked with runhaskell is a
separate issue.  For simplicity in bootstrapping, I think it should.
Perl and Python also do it this way, as I understand.

> We can do so without losing any flexability at all. just add a new line
> to the cabal file
>
> build-style: (makelike|simple|custom)

> where makelike and simple just call the current cabal library routines
> and custom lets you specify a command that should be run and arguments
> passsed to it. (which can be something like 'runhaskell Setup.lhs')

Simon pointed out one problem with this.  I'm definitely thinking
about relaxing the Setup.hs requirement, but I only want to do this
once we understand the implications.  Those implications will become
more clear once we have things like cabal-install and cabal-get in
active use.  If almost everyone is using cabal-install and
defaultMain, then a two-line tweak to cabal-install will relax the
Setup.hs requirement.

> seperating cabal into its own program would also be a good place to
> provide a unified compiler independent 'runhaskell' script that can have
> logic for finding and running an appropirate compiler so people don't
> have to maintain an appropriate link to runhugs,runghc, or runjhc...

I don't think this really has anything to do w/ Cabal, and I don't see
why they should be bundled.  There's certainly no logic in Cabal right
now that'll make compiler preferences particularly easy to implement.

> while having a source code interface makes a lot of sense for
> single-source implementation-defined languages like perl, I think it is
> very inappropriate for multi-source, compiled programs. Especially when
> it gains you absolutly nothing other than headaches. The chance that
> someone will have such an absurdly odd build setup that one of the
> standard cabal models won't apply AND they can simulate the cabal
> interface exactly are virtually nil and if such a thing does exist, a
> build-style: custom will take care of it.

As Simon pointed out, build-style: custom is implemented w/ hooks
right now, and there are certainly programs out there using hooks,
though not many of them.  They're not particularly absurd build
systems either.

> You might not even have a haskell compiler on the system you want to
> run cabal on.  (cross-compiling, bootstrapping)

You could always compile the setup script on the cross-compiling
machine.  I do like cabal-install, though, and I think that's the way
of the future.


peace,

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

Re: cabal release

Isaac Jones-2
In reply to this post by Simon Marlow
"Simon Marlow" <[hidden email]> writes:

> On 12 December 2005 15:31, Ian Lynagh wrote:
>
>> On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
>>>
>>> In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1.
>>> That is after installing GHC 6.4.1 we unregister Cabal-1.0 and
>>> install Cabal-1.1.3.
>>
>> If all distributions and users are going to have to do this to get a
>> usable system[1] then it seems obvious to me that ghc should already
>> come this way. That it doesn't causes headaches for packagers IME.
>
> I tend to agree.  I'm not against breaking the rules in this case, since
> shipping Cabal-1.0 in 6.4.2 would be distinctly sub-optimal.  Shipping
> two versions of Cabal is possible, but the build system isn't really set
> up to do this, so it's non-trivial work, and it still requires the user
> to say 'ghc-pkg expose Cabal-1.1.4; ghc-pkg hide Cabal-1.0'.

Cool :)  What's the timeline for ghc 6.4.2?

> Cabal is something of a special case,

Aw shucks ;)

> I'd be rather happier if we could solve the versioning issue with
> Cabal, so that upgrading Cabal in the future doesn't automatically
> break code.  It might not be possible to do this the first time
> around, but now is the time to design our way out of future
> problems.

We need to experiment with stuff.  People want to use the advanced
features like hooks on complex packages, but no one wants the
cabal-1.0 interface to hooks!  We're trying to maintain a tension
between experimenting and providing something stabler for simple
programs (just like Haskell itself).  It's bad if that breaks stuff,
but I don't want to end up in a situation where we tie ourselves to a
bad implementation because 3 packages used the old interface.  I think
we just need to be better about explicitly stating what is stable and
what is not.


peace,

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

Re: cabal release

Ketil Malde-2
In reply to this post by Isaac Jones-2
Isaac Jones <[hidden email]> writes:

> I propose that each haskell compiler / interpreter come with
> runhaskell.  It should check to see whether runhaskell exists already
> and if so, leave it alone.  If not, provide it.  

Shouldn't replacement be the default?  I think a typical user will
stick with one Haskell implementation, and just upgrade it once in a
while - in which case replacement is probably what is desired.

Anyway, I expect most users to install via OS packages (rpm,deb,..),
and distributions tend to have their own solutions for this kind of
thing (/etc/alternatives springs to mind).

> That should probably be tweakable with the configure script.

'runhaskell' could perhaps also be a small script that checks for the
availability of 'runhugs', 'runghc', etc.  This way, it could be the
same for all Haskell implementations, and the choice could be
configurable on a user basis (rather than per system).  It would cost
a bit of startup time, though.

-k
--
If I haven't seen further, it is by standing in the footprints of giants

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

RE: cabal release

Simon Marlow
In reply to this post by Isaac Jones-2
On 14 December 2005 01:28, Isaac Jones wrote:

> "Simon Marlow" <[hidden email]> writes:
>
>> I'd be rather happier if we could solve the versioning issue with
>> Cabal, so that upgrading Cabal in the future doesn't automatically
>> break code.  It might not be possible to do this the first time
>> around, but now is the time to design our way out of future
>> problems.
>
> We need to experiment with stuff.  People want to use the advanced
> features like hooks on complex packages, but no one wants the
> cabal-1.0 interface to hooks!  We're trying to maintain a tension
> between experimenting and providing something stabler for simple
> programs (just like Haskell itself).  It's bad if that breaks stuff,
> but I don't want to end up in a situation where we tie ourselves to a
> bad implementation because 3 packages used the old interface.  I think
> we just need to be better about explicitly stating what is stable and
> what is not.

Absolutely, I understand that.  I'm not suggesting every tiny revision
of the interface must be available for ever.

But I think it would help a great deal if a Cabal release could support
the previous, say, 1 or 2 major revisions of the interface, just to
smooth the transition, so that a new release didn't automatically break
a lot of packages.  

eg. Setup.lhs would do this:

  import Distribution_1_2.Simple
  main = defaultMain

all we have to do is provide Distribution_1_2.*.  When we freeze a
version, we create a bunch of stubs under Distribution_<ver>, using
explicit export lists everywhere.  Sometimes we'll have to add some
backwards compatibility code.

The latest experimental version of the interface is always available as
Distribution.* (or maybe Distribution_cur.*, or something), with
appropriate warnings generated by DEPRECATED pragmas that the interface
is subject to change.

I've been thinking about adding support to Haddock to compare versions
of interfaces and tell you what the changes are, this would be great for
documentation and also to make sure that we aren't breaking interfaces.

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

Re: cabal release

Malcolm Wallace
In reply to this post by Ketil Malde-2
Ketil Malde <[hidden email]> writes:

> 'runhaskell' could perhaps also be a small script that checks for the
> availability of 'runhugs', 'runghc', etc.  This way, it could be the
> same for all Haskell implementations, and the choice could be
> configurable on a user basis (rather than per system).  It would cost
> a bit of startup time, though.

I have been thinking about extending 'hmake' with this functionality.
'hmake' already has a full infrastructure for configuring multiple
compiler installations, so the 'runhaskell' script can be a very
simple front-end over hmake - in fact the only difference is that it
runs the generated executable in addition to building it.

An experimental version is in hmake's CVS, called runhs.hs, if anyone
wants to play with it.
    http://cvs.haskell.org/cgi-bin/cvsweb.cgi/nhc98/src/hmake/

The main thing currently missing from hmake is support for building
with Hugs (mainly because it is a NOP), but a call to runhugs will
be easy to add.

Regards,
    Malcolm
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12