On 14/08/2008, at 18:01, Simon Marlow wrote:
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is
really unnecessary and could be done by Cabal since it only or
mostly depends on the package information. Instead, it is
implemented somewhere in Distribution.Simple and not really usable
from the outside. For instance, a lot of the functionality of setup
sdist, setup register and so on could be implemented generically
and used by a make-based build system as well.
That's exactly what I'm proposing we do in GHC: re-use Cabal's setup
register and some of the other parts of the simple build system in a
make-based build system for packages. It might require a bit of
refactoring of Cabal, but I don't expect it to be a major upheaval
at all.
Ah! I hadn't realised that you are going to reuse Cabal functionality.
You wrote "Extract the code from Cabal that generates Makefiles" so I
thought you won't be really using anything from Cabal.
I think what you're proposing is mostly a matter of abstracting
parts of Cabal with cleaner and more modular APIs, which is
absolutely a good thing, but doesn't require a fundamental
redesign. The tight coupling and lack of separation between Cabal's
generic parts and the simple build system is somewhat accidental
(lazy implementors :-), and is actually a lot better than it used to
be thanks to the work Duncan has put in. I'm sure it'll improve
further over time.
IMO, getting this right is absolutely crucial for Cabal's usability
and should be the primary short-term goal. Then again, I guess I
should contribute code instead of opinions already :-)
The other part of your complaint is that the BuildInfo is in
the .cabal file along with the PackageDescription (the types are
pretty well separated internally). Again I don't think there's
anything fundamental here, and in fact some packages have
separate .buildinfo files.
Well, it is fundamental in the sense that this is how Cabal is used
(and is supposed to be used) at the moment. It is good that Cabal
separates these things internally but the separation should be
enforced in the external interface, as well.
Roman
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
