cabal design

[Lemmih]

On 8/20/05, Frederik Eaton <frederik at a5.repetae.net> wrote:
> On Fri, Aug 19, 2005 at 10:11:52AM -0700, Isaac Jones wrote:
> > Frederik Eaton <frederik at a5.repetae.net> writes:
> >
> > > On Mon, Aug 15, 2005 at 08:52:18AM -0700, Isaac Jones wrote:
> > >> Frederik Eaton <frederik at a5.repetae.net> writes:
> > >>
> > >> > 1) Cabal files can have different names, yet only one can exist in a
> > >> > directory. I've been told that the reason for the former is that Isaac
> > >> > wants to support building multiple packages in a directory, but
> > >> > currently the feature isn't implemented, so only one cabal file is
> > >> > allowed.
> > >> >
> > >> > Certainly, it would be a nice feature, but more importantly it seems
> > >> > that it would require some API changes or additions which should be
> > >> > made sooner rather than later. Is there a document describing how it
> > >> > would work? Is there a roadmap, a schedule for implementation?
> > >>
> > >> I'm not so sure that the change is very big at all... it should just
> > >> be a matter of adding a feature to allow libraries to register
> > >> themselves "in-place" or something... then compute the dependencies
> > >> between the packages, build them in order, install the libraries
> > >> you'll need in-place, then compile the programs.
> > >>
> > >> The problems come up where a package might need to actually be in the
> > >> install location in order to work.  Hopefully that's not too common.
> > >
> > > This sounds rather vague. For instance, how does it interact with
> > > configure/make based packages?
> >
> > If they conform to the cabal standard, providing configure, build, and
> > install steps, then they are built exactly the same.  Can you be more
> > specific about your question?
> 
> What I meant is, if a 'make'-based build depends on a cabal package
> being installed in a temporary location, how do we communicate to the
> 'make'-based build what that temporary location is? There needs to be
> some standard mechanism and it is important to facilitate some sort of
> discussion about it so that the right standard mechanism is agreed
> upon. It's not trivial, there is a package database, a base for
> library files and executables, and these have to be communicated to
> different kinds of compilers... I expect that even how things will
> work with standard cabal packages will not be trivial.
> 
> > > What do you think about putting a TODO list linking to designish
> > > documents on the wiki, so that people can flesh these plans out and
> > > comment on them there?
> >
> > Sure.  Feel free to add a wiki page for this.  There's a TODO list in
> > the darcs repository, but it may not be understandable by anyone but
> > me; it still might be a good place to start.
> 
> Maybe we'll need your help on the TODO list part. I'm willing to
> contribute ideas once the structure
> 
> > I caution you, though, on spending too much time making plans and
> > designs and not much time writing code; the problem is usually that we
> > have plenty of ideas about what needs to get done and not enough
> > coders.  The code base is pretty manageable, so if you want to help
> > out, just pick something you think needs to get done, or ask me what
> > is most important and start working on it :) I usually ask for help on
> > this list when something comes up.
> 
> I caution you on the opposite. Cabal is very format and
> protocol-heavy. I imagine that much of the work has gone into
> documentation and mindshare, in which case it becomes very important
> to keep people informed and working together. Suggesting that
> individuals need to contribute patches unilaterally before anything
> will happen seems counterproductive to me, at least when it comes to
> some of the larger parts.
> 
> On a meta-tangent, if we could be discussing things on a wiki, rather
> than a mailing list, then I think discussions could go a lot faster.
> For instance: person A says something, person B asks for
> clarification, person A amends what he says and deletes person B's
> request. On a list you have 3 messages, on a wiki you have 1. So
> asking someone to "go read the thread" doesn't sound so ridiculous
> anymore. If it were a wiki with email notification capabilities, then
> it would be even better since it could evolve in real time. This is
> the sort of thing I'm advocating. Partly because I think it would be
> good for Cabal, partly because I want to do the experiment. Only if
> other people think it's a good idea though.
> 
> > Something that you could spend a few hours on is getting the test
> > suite to run conveniently on other people's computers, and figuring
> > out how to get Hugs to pick up changes directly from the current
> > directory during testing.
> >
> > >> > 3) The way that a 'cabal' package with a 'configure' script should be
> > >> > built is not easy to determine. There are some very useful programs
> > >> > (http://toastball.net/toast/) which build and manage packages of all
> > >> > kinds automatically, by running 'configure' with a local prefix, etc.
> > >> > How should these tools be extended to work with 'cabal' packages? With
> > >> > some 'cabal' packages, the user is supposed to run 'configure' first,
> > >> > and then 'runhaskell Setup.hs'. With other 'cabal' packages, the user
> > >> > is supposed to just run 'runhaskell Setup.hs', and this will run
> > >> > 'configure' automatically. Is there a right way? Is there a way to
> > >> > distinguish the two types of packages automatically?
> > >>
> > >> What packages require you to run configure by hand?
> > (snip)
> > > I don't know of any packages off-hand.
> >
> > Whew
> >
> > > I think my friend who wrote "toast" may have found one, but he may
> > > also have just liked 'configure' better. Anyway, it's good to know
> > > that there is a standard. It might be good for the manual to mention
> > > explicitly that configure/make are always run by Setup.hs and not
> > > vice-versa.
> >
> > Here's a good example; the manual is in the darcs repository,
> > doc/cabal.xml, I think.  Just go ahead and add that and send me a
> > darcs patch :)
> 
> I've attached a patch.
> 
> > >> > 4) Cabal's inability to let users specify package.conf-s other than
> > >> > the user or global package.conf
> > >>
> > >> I think the gentoo guys were going to implement this for us; in any
> > >> case, it's a subset of 1).  This should be pretty easy; the only
> > >> question is whether we should have a --in-place or a
> > >> --package-conf=... Where in-place would choose a "standard" one
> > >> (./packages.conf or something).  The reason I'd prefer the former is
> > >> that not all systems _have_ an idea of a package.conf file, so
> > >> --package-conf= would make no sense for most compilers.  I try to
> > >> avoid that.  The reason for the later would be if there's some
> > >> use-case that --in-place does not work for.
> > >
> > > Is it really a subset of (1)? I don't think it is.
> > >
> > > I think a --package-conf= would be very nice. If it is not supported
> > > by the compiler, then an error should be generated.
> >
> > In a way, the problem isn't "lack of support" but a different model of
> > finding packages... It's not like a compiler extension that one system
> > supports and one doesn't; this flag breaks abstraction between
> > compilers in a way that --in-place does not.  I haven't heard any use
> > cases where --in-place won't work.
> 
> Well, we're talking about two different features here. I want to be
> able to specify an arbitrary location. You want to be able to specify
> the current working directory. Not the same thing, is it? I think it
> should be possible to specify an arbitrary location, at least for ghc.
> 
> > (snip)
> > >> > 5) It seems that there should be a way to build multiple packages
> > >> > which depend on each other, in such a way as that the first package
> > >> > doesn't have to be installed for the second package to be built. In
> > >> > other words, perhaps something like a dummy installation as in #4 is
> > >> > called for. I have seen mention that support for building multiple
> > >> > packages is planned, but how? When?
> > >>
> > >> This is the same as 1.
> > >
> > > Well, not if they aren't in the same directory. Again, we need to have
> > > more explicit details about how things are planned to work.
> >
> > Hackage is the tool here; it's still almost ready.  It has 19 module
> > dependencies and is a pain to bootstrap.  We've written about it here
> > & there, but if you can't dig up concrete information, come onto
> > #haskell and ask Lemmih what's up.

I've recounted it to 17 and 14 if you count the hs-plugins and HSX
packages singles.

> 
> I was thinking something like WASH, where the packages are in
> different directories, but they aren't registered in some sort of
> central database.
> 
> BTW, I find that Haskell modules are simple enough to maintain and
> merge that sticking these 19 hackage modules into 1 might not be too
> bad of an idea.

He meant packages and not modules.

> > >> > 6) I think it should be easy to use 'cabal' for development; however,
> > >> > when I am building a package with multiple executables, every 'build'
> > >> > seems to re-link each executable, regardless of whether it needs
> > >> > re-linking or not, which is quite slow.
> > >>
> > >> I'm not sure why ghc --make re-links executables every time.
> > >>
> > >> For libraries, I think we could use support from ghc to tell whether
> > >> we need to re-link the library; ghc goes through and skips stuff that
> > >> doesn't need to get built, and then we link everything in the library;
> > >> if ghc could somehow let us know that nothing needed to get built,
> > >> that would be very helpful; otherwise, someone has to write the logic
> > >> to go through and check it all just like ghc does.  This code should
> > >> be out there somewhere.
> > >
> > > Isn't there a way to get ghc to emit Makefile fragments which solves
> > > this problem? Not that solving it in ghc wouldn't be good as well.
> >
> > Relying on Make isn't any good for us for the simple build
> > infrastructure; it needs to be more portable than that.
> 
> Really? Surely every platform has some basic 'make' installed. And
> just parsing out the rules can't be that hard.
> 
> Frederik
> 
> --
> http://ofb.net/~frederik/
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 
> 
> 
> 


-- 
Friendly,
  Lemmih