cabal design

[Frederik Eaton]

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?

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?

> > 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?  That is indeed
> incorrect in the sense that it doesn't conform to the cabal interface.
> If the packager is doing that in order to alter the .cabal file, then
> that's a problem... the correct way to do this is covered in the
> manual, and configure has built-in support in cabal.

I don't know of any packages off-hand. 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.

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

> > , and ghc's refusal (and that of other
> > compilers) to let users specify paths for things via environment
> > variables,
> (snip)
> > To lag behind 'gcc' and 'autoconf' is not acceptable.
> 
> GCC lets you specify things via environment variables?  I've never
> seen that... if ghc were to adopt this kind of behavior, I hope it
> wouldn't be the default; as in 'make', it should require an extra flag
> like -e.

Mostly CPATH and LIBRARY_PATH. Perhaps, variants for other languages.

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

> > What stage of implementation are we in?
> 
> We're in the stage of "Isaac has been too busy writing papers and book
> reviews and needs to get working."  I'm always happy to get patches,
> though.

OK, correct me if I'm wrong but I think we need to tell people what
kind of patches to write, and ask them to write them, to get things
moving.

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

> > I'm not sure how much of this Isaac has planned out on his own and is
> > busy implementing, vs. how much is waiting for someone to write a
> > design document for. 
> 
> You're always welcome to submit patches and suggestions on how to do
> stuff, and I and other folks here will be more than happy to engage
> you.  I've been a little too distracted with other stuff, and keep
> hoping that GHC 6.4.1 will appear so I can release cabal 6.2 and get
> hacking on other stuff.  I should just make a 'stable' branch or
> something.
>
> Finally, thanks for all of your great suggestions.  We need feedback
> from as many different users as possible.  We've spent a long time
> guessing about what folks might need, and now that cabal is in the
> wild, we're getting good feedback about what they actually need :)

You're welcome.

Frederik