cabal beginner issues (other-modules, build-depends)

Simon Marlow simonmar at microsoft.com
Fri Sep 23 05:37:52 EDT 2005


On 23 September 2005 10:20, Ross Paterson wrote:

> On Fri, Sep 23, 2005 at 09:50:18AM +0100, Simon Marlow wrote:
>> On 23 September 2005 08:45, Johannes Waldmann wrote:
>> 
>>>> Another way to look at both issues is that if ghc can figure out
>>>> other modules and packages itself, the user shouldn't be required
>>>> to specify them in a cabal file. ...
>>> 
>>> Definitely. Having the list of modules in the .cabal is unnecessary
>>> duplication of information (because it's in the sources already).
>>> This is bound to get out-of-sync during development -
>>> unless you use some kind of Makefile to generate the .cabal file,
>>> which defeats the very purpose of Cabal itself.
> 
> Module dependency calculation would have to be done in the build
> environment, not at the source, because the set of modules used may
> be system-dependent.  And you'd still need to specify exposed-modules.

Yes, that's what I had in mind.  The calculation of other-modules would
happen when .installed-pkg-info is generated.

>> I know how to do this using GHC, but I'm not sure about other
>> compilers. With GHC, we can generate the dependencies using 'ghc -M'
>> and then parse the generated Makefile (a bit of a long way around,
>> but I can't think of an easier way).  Of course we'd avoid splatting
>> an existing Makefile by redirecting the dependencies to a temporary
>> file. 
>> 
>> How would we do this with nhc98 or Hugs?  Perhaps because these
>> systems don't actually need to know the value of other-modules we
>> can get away with it.  Comments?
> 
> Cabal/Hugs needs other-modules to produce a complete package
> (if modules are omitted the build succeeds but using it fails).

Ah yes, good point.  Since we can't do this unversally, perhaps it's not
worth doing.

Cheers,
	Simon


More information about the Libraries mailing list