headers
Thomas Hallgren | 2 Dec 2004 04:43
Picon

Re: The Fudgets Library

Hi,

David Owen wrote:

> I am having trouble installing and using the Fudgets library.  I am 
> using SuSe Linux 9.0 and Fudgets version h13w May 2002...

More recent versions of Fudgets can be downloaded from

    http://www.cse.ogi.edu/~hallgren/untested/

I don't use SuSe Linux, so I am not sure what the best way is to install 
GHC. The following might work:

<><>wget http://www.haskell.org/ghc/dist/6.2.2/RedHat9.0/ghc-6.2.2-1.i386.rpm
wget http://www.cse.ogi.edu/~hallgren/untested/for_Linux/fudgets-041119-ghc-6.2.2-i386-linux-fc2.tar.gz
rpm -Uvh ghc-6.2.2-1.i386.rpm
tar -C /usr/local -zxf fudgets-041119-ghc-6.2.2-i386-linux-fc2.tar.gz
...
ghcxmake Main
./Main

--

-- 
Thomas H

"Delay is preferable to error."
  - Thomas Jefferson (3rd President of the United States)
Permalink | Reply | 0 comments |
headers
Isaac Jones | 2 Dec 2004 06:21
Picon

Cabal package description sytax

Hi Ross,

I'm definitely happy to add more optional fields to the package
description file.  I knew that the need for such would come up.

But the interface to cabal is the required description file fields and
the required Setup arguments.  How do you maintain that interface if
you're generating the required fields of the description file with the
Setup program itself? (I'm assuming that you are having Setup
configure call the ./configure script or something?)

The idea behind making the cabal description file so easy to parse is
that other tools can get information like the package name and version
from the cabal description file, rather than the description file
sucking it in from someplace else.  I believe this is what the Debian
package generation tools do, for instance.

Where do the PACKAGE_NAME, etc. values come from, BTW?

A hope with the cabal was to be able to have a Setup.description file
at the top level of something like a tarball.  Layered tools like
Hackage know where it is and how to parse it.  If you don't have it in
the source tarball, but rather generate it during build time, that
breaks this model.

The simple build infrastructure is not meant to build everything,
though it would be nice if it could build most things without the help
of Make and friends.  The key is the interface to cabal which allows
for layered tools like Hackage and the Debian package generator to
come about.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Simon Marlow | 2 Dec 2004 10:53
Picon
Favicon

RE: Cabal package description sytax

On 02 December 2004 05:22, Isaac Jones wrote:

> I'm definitely happy to add more optional fields to the package
> description file.  I knew that the need for such would come up.
> 
> But the interface to cabal is the required description file fields and
> the required Setup arguments.  How do you maintain that interface if
> you're generating the required fields of the description file with the
> Setup program itself? (I'm assuming that you are having Setup
> configure call the ./configure script or something?)
> 
> The idea behind making the cabal description file so easy to parse is
> that other tools can get information like the package name and version
> from the cabal description file, rather than the description file
> sucking it in from someplace else.  I believe this is what the Debian
> package generation tools do, for instance.

It seems that we want a format the for the Setup.description file that
can both

 (a) be parseable without any preprocessing to extract a well-defined
     subset of the full contents (eg. package name, version,
     maintainer, description etc.)

 (b) be combined with information collected by './Setup.lhs configure'
     to form a complete PackageDescription.

could we just make up a syntax for splicing in information from the
configure step into Setup.description?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ross Paterson | 2 Dec 2004 15:35
Picon
Favicon

Re: Cabal package description sytax

On Wed, Dec 01, 2004 at 09:21:33PM -0800, Isaac Jones wrote:
> But the interface to cabal is the required description file fields and
> the required Setup arguments.  How do you maintain that interface if
> you're generating the required fields of the description file with the
> Setup program itself? (I'm assuming that you are having Setup
> configure call the ./configure script or something?)
> 
> The idea behind making the cabal description file so easy to parse is
> that other tools can get information like the package name and version
> from the cabal description file, rather than the description file
> sucking it in from someplace else.  I believe this is what the Debian
> package generation tools do, for instance.

I suppose what I'd like is a separation of the build information from
the basic package description, with the possibility of the configure step
producing the build info to be used by the simple build infrastructure.
Having hardwired build info is very limiting.

> Where do the PACKAGE_NAME, etc. values come from, BTW?

They're set by AC_INIT in configure.ac.  That was Sven's concern, but
you make a strong case for it originating from the package description.
(Nothing to stop configure getting it from there, I imagine.)

I'm more concerned about the build information: C compiler options,
libraries, include files, frameworks, etc.  And the hidden module list,
possibly the exposed ones too (though maybe you want that available
to your tools).

> A hope with the cabal was to be able to have a Setup.description file
(Continue reading)

Permalink | Reply | 4 comments |
headers
Keean Schupke | 3 Dec 2004 13:04
Picon

Cabal and installing packages.

Just been thinking about making Haskall packages easy to use and 
install, and someone
suggested I looked at Cabal.

It seems to me at first glance that something important is missing... If 
we imagine some
easy to use wrapper program for the user, which would allow them to 
specify a library by name, and which would download a list of mirrors 
from haskell.org, then fetch the package, configure, compile and install 
it. It seems the library author should specify the dependancies of their 
library so that the prequisit packages can be fetched first.

My question is does Cabal require the package author to specify 
dependancies, and if not, perhaps it should.

    Regards,
    Keean.
Permalink | Reply | 0 comments |
headers
Simon Marlow | 3 Dec 2004 17:14
Picon
Favicon

RE: Cabal and installing packages.

On 03 December 2004 12:05, Keean Schupke wrote:

> My question is does Cabal require the package author to specify
> dependancies, and if not, perhaps it should.

Yes it does.  Next question :)

Simon
Permalink | Reply | 1 comment |
headers
Keean Schupke | 3 Dec 2004 17:24
Picon

Re: Cabal and installing packages.

Cool, I should have paid more attention to the Cabal stuff... Next 
question is;

Is there planned to be a front-end for fetching packages, that would let 
you download
and install a package (and all its dependancies) from the command line? 
All I could
find were the ./setup <option> commands?

    Keean.

Simon Marlow wrote:

>Yes it does.  Next question :)
>
>Simon
>  
>
Permalink | Reply | 0 comments |
headers
Simon Marlow | 3 Dec 2004 17:47
Picon
Favicon

RE: Cabal and installing packages.

On 03 December 2004 16:24, Keean Schupke wrote:

> Cool, I should have paid more attention to the Cabal stuff... Next
> question is;
> 
> Is there planned to be a front-end for fetching packages, that would
> let you download
> and install a package (and all its dependancies) from the command
> line? All I could
> find were the ./setup <option> commands?

If you're on a system with a good package manager (i.e. *BSD, Debian,
Gentoo) then the plan is that this is all handled by the system package
manager.  We don't want to duplicate that work, and we want to coexist
with the system's package tools as much as possible.  Cabal will make it
easy to generate package skeletons for these systems.

We don't have a good story for the rest yet - that includes systems that
don't have a package manager, and when you want to install packages in
your own filespace on a multi user machine.  A tool to do what you
describe would definitely help here.

Cheers,
	Simon
Permalink | Reply | 8 comments |
headers
Keean Schupke | 3 Dec 2004 18:10
Picon

Re: Cabal and installing packages.

Simon Marlow wrote:

>If you're on a system with a good package manager (i.e. *BSD, Debian,
>Gentoo) then the plan is that this is all handled by the system package
>manager.  We don't want to duplicate that work, and we want to coexist
>with the system's package tools as much as possible.  Cabal will make it
>easy to generate package skeletons for these systems.
>  
>
I find that even on package managed systems I use CPAN to install perl
modules... I would have thought a nice central repository on haskell.org
(with mirrors of course) where users can contibute their packages, that
would be built into a Haskell package tool would be useful even for
systems where there is package management.

I find that debian/gentoo etc do not have all the packages available
for say perl, and it is nice to have a consistant interface on any 
platform...

I think the ability to do (something like)

    > cabal install <package-name>

and have everything done automatically would be a real advantage for 
beginners, ie:

    - download mirror list from haskell.org
    - find closest mirror using DNS tld
    - download package
    - resolve dependancies (ie call "cabal install" for each required
(Continue reading)

Permalink | Reply | 7 comments |
headers
Daan Leijen | 3 Dec 2004 20:19
Picon

Re: Cabal and installing packages.

Keean Schupke wrote:
> Simon Marlow wrote:
> 
>> If you're on a system with a good package manager (i.e. *BSD, Debian,
>> Gentoo) then the plan is that this is all handled by the system package
>> manager.  We don't want to duplicate that work, and we want to coexist
>> with the system's package tools as much as possible.  Cabal will make it
>> easy to generate package skeletons for these systems.

Hi all,

I just wanted to say that I do agree with Keean here: A *simple* install
manager for Haskell modules with a central repository would be great!

Having said that, there are strong reasons for not doing this. The most
important one is that a good package manager is not trivial and there
already exist good package manager for many systems.

Still, for 90% of all potential Haskell libraries, we can get away with
a fraction of the effort of building a real package manager. This can
really work, as long as we stick with a *simple* solution that is 
clearly described and whose limits are well defined. If someone requests
something beyond the limits, we redirect to the OS package manager.
With a clear and simple design, an implementation should not require
too much effort or resources. (Actually, as I said before, a clear 
design with well defined limits is probably essential or otherwise the 
implementor will never be done :-)

Now, I do not propose to do this myself :-), but I surely think that if
there is anyone interested on this list on doing this, it would make a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane