cabal design
Frederik Eaton
frederik at a5.repetae.net
Sat Aug 20 01:49:46 EDT 2005
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 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.
> >> > 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/
-------------- next part --------------
--- old-cabal/doc/Cabal.xml 2005-08-19 22:11:45.000000000 -0700
+++ new-cabal/doc/Cabal.xml 2005-08-19 22:36:54.000000000 -0700
@@ -842,14 +842,33 @@
<listitem>
<para>If the package root directory contains a file called
<filename>configure</filename>, the configure step will
- run that. This <filename>configure</filename> program may
+ run that. This <filename>configure</filename> program may
be a script produced by the <command>autoconf</command>
- system, or may be hand-written. This program typically
+ system, or may be hand-written. This program typically
discovers information about the system and records it for
- later steps, e.g. by generating system-dependent header files
- for inclusion in C source files and preprocessed Haskell
- source files. (Clearly this won't work for Windows without
- MSYS or Cygwin: other ideas are needed.)</para>
+ later steps, e.g. by generating system-dependent header
+ files for inclusion in C source files and preprocessed
+ Haskell source files. (Clearly this won't work for Windows
+ without MSYS or Cygwin: other ideas are needed.) N.B.:
+ Although <literal>defaultMain</literal> doesn't always
+ check for a file named <filename>configure</filename>, if
+ one such file does exist, it should always be run by
+ <filename>Setup.hs</filename> rather than vice-versa. So
+ if you are a generic packaging tool, and you see a file
+ named <filename>Setup.hs</filename> or
+ <filename>Setup.lhs</filename> as well as a file named
+ <filename>configure</filename>, then you should invoke
+ Cabal via <filename>Setup.[l]hs</filename> and not
+ <command>autoconf</command> via
+ <filename>configure</filename>. Likewise, if you are a
+ programmer putting together a Cabal package, and need to
+ do <command>autoconf</command> configuration, you should
+ do it through Cabal using e.g.
+ <literal>defaultMainWithHooks</literal>, and ask the user
+ to invoke everything through
+ <filename>Setup.lhs</filename> - rather than telling the
+ user to run <command>./configure</command> first and, say,
+ using that to generate a Cabal file.</para>
</listitem>
<listitem>
More information about the Libraries
mailing list