cabal beginner issues (other-modules, build-depends)
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
>> 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
More information about the Libraries