dumb cabal question

[Isaac Jones]

Frederik Eaton <frederik at a5.repetae.net> writes:

> On Sun, Sep 04, 2005 at 08:01:48PM -0700, Isaac Jones wrote:
>> The reason to combine them is that the point of abstraction between
>> the compilers / interpreters lives in areas like "preprocess this
>> file", "build this file", "install this library", not in operations
>> like you mentioned:
>
> I mentioned the second two of those, but not the first one.

You mentioned taking a .hs file and producing a .o file; that's not
actually the same thing.  Hugs doesn't use .o files, but if you look
at Distribution.Simple.Build, you'll see that "building" for hugs
(that is, preparing for installation) is far from a no-op.

You mentioned "taking a package and installing it into a package
database" but of course, Hugs doesn't have a package database, as
we've discussed, and actually "installing" (that is, making libraries
and executables available to end users) for Hugs is also not just a
matter of copying some files over.

So in short, the reason we don't put the level of abstraction into the
operations you mention is because they aren't shared between the
compilers / interpreters, so there's nothing to abstract.  It's
probably the case, though, that actual compilers like ghc, jhc, and
nhc have much more similar models, and there could be some useful
abstractions there.

> Preprocessing files, however, doesn't sound like an operation that
> needs to be done in a compiler/interpreter-specific way.

That's true, ther's almost no compiler-specific code in
Distribution.PreProcess, except to pass some definitions to CPP.

peace,

  isaac

>> > There would be operations such as: compile a file into an object
>> > file (may be a no-op); link a bunch of object files into a package;
>> > install a package into the following package database; create an
>> > empty package database; merge two package databases; find
>> > dependencies of a module. And options like: use the following other
>> > packages, search for packages in the following package database.
>> 
>> Each of these operations would be a no-op for Hugs, and yet the
>> abstraction layer that Cabal provides works quite well for Hugs.  I
>> think that if we had built a standard command-line interface between
>> compilers, GHC and Hugs would have almost disjoint operations, and
>> Cabal would still have to perform the same amount of work, since it
>> couldn't actually use this interface to get its job done.
>
> -- 
> http://ofb.net/~frederik/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries