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

newer
Network Exception

older
making with profiling, 6.4.1,...

Simon Marlow

23 Sep 2005 23 Sep '05

4:50 a.m.

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.

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?

...

Unrelated question: can someone please share an example that shows how to put user-defined options for haddock in a .cabal?

There's no good way to do it right now. You can override the whole haddock command using hooks, but you'd have to write quite a bit of code to do this. I plan to add something to allow extra Haddock args to be given (the Haddock support is a very bare-bones right now, it should get better). Cheers, Simon

Show replies by date

Ross Paterson

23 Sep 23 Sep

5:19 a.m.

New subject: cabal beginner issues (other-modules, build-depends)

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.

...

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). Cabal/nhc98 doesn't need anything, because it doesn't exist.

Malcolm Wallace

5:42 a.m.

New subject: cabal beginner issues (other-modules, build-depends)

"Simon Marlow" writes:

...

With GHC, we can generate the dependencies using 'ghc -M' and then parse the generated Makefile. ... How would we do this with nhc98 or Hugs?

hmake -M Foo | tail +2 | cut -d' ' -f2 works independently of any compiler. If there are compiler-specific imports selected by cpp directives, then hmake -hc=ghc-6.2.2 -M ... Regards, Malcolm

Isaac Jones

11 Oct 11 Oct

1:23 p.m.

New subject: cabal beginner issues (other-modules, build-depends)

Malcolm Wallace writes:

...

"Simon Marlow" writes:

...
With GHC, we can generate the dependencies using 'ghc -M' and then parse the generated Makefile. ... How would we do this with nhc98 or Hugs?

hmake -M Foo | tail +2 | cut -d' ' -f2

works independently of any compiler. If there are compiler-specific imports selected by cpp directives, then

hmake -hc=ghc-6.2.2 -M ...

We really should add depenency analysis to Cabal directly. The only reason to avoid this, afaik, is that parsing the imports might be a little tricky. I don't think that hmake necessarily handles every possible case here, semi-colons separating lines and multi-line comments, for instance (though maybe it does handle these, I might be wrong). It does a good job, and we can use that code in Cabal as well. FWIW, I'm working on code to add --with-haddock-args to configure, so no one else needs to worry about that right now. It's almost done. peace, isaac

Malcolm Wallace

5:39 p.m.

New subject: cabal beginner issues (other-modules, build-depends)

Isaac Jones writes:

...

We really should add depenency analysis to Cabal directly.

Indeed. I had the impression that eventually Cabal hopes to be a complete replacement for hmake in many ways.

...

The only reason to avoid this, afaik, is that parsing the imports might be a little tricky. I don't think that hmake necessarily handles every possible case here, semi-colons separating lines and multi-line comments, for instance (though maybe it does handle these, I might be wrong). It does a good job, and we can use that code in Cabal as well.

hmake certainly handles multi-line comments, and #ifdef'd conditional imports (by using cpphs as a library). It used to have a problem with para-Haskell sources, e.g. where a Happy grammar defined a symbolname 'import', but now it is clever enough to avoid those too. I think the only thing not handled entirely correctly is several import statements on the same line separated by semicolons. Not only is this situation extremely rare, but I've just thought of an easy way to make it work right anyway. Regards, Malcolm

Isaac Jones

8:05 p.m.

New subject: cabal beginner issues (other-modules, build-depends)

Malcolm Wallace writes:

...

Isaac Jones writes:

...
We really should add depenency analysis to Cabal directly.

Indeed. I had the impression that eventually Cabal hopes to be a complete replacement for hmake in many ways.

I would like to have enough stuff in the API so that you could implement HMake on top of the Distribution.* architecture, basically.

...

...
The only reason to avoid this, afaik, is that parsing the imports might be a little tricky. I don't think that hmake necessarily handles every possible case here, semi-colons separating lines and multi-line comments, for instance (though maybe it does handle these, I might be wrong). It does a good job, and we can use that code in Cabal as well.

hmake certainly handles multi-line comments, and #ifdef'd conditional imports (by using cpphs as a library).

Great. I had some vague memories about HMake's parser for input statements being over simple, so I'm sorry I was incorrect there.

...

It used to have a problem with para-Haskell sources, e.g. where a Happy grammar defined a symbolname 'import', but now it is clever enough to avoid those too. I think the only thing not handled entirely correctly is several import statements on the same line separated by semicolons. Not only is this situation extremely rare, but I've just thought of an easy way to make it work right anyway.

Cool. Maybe we can steal your code :) peace, isaac

Malcolm Wallace

12 Oct 12 Oct

5:58 a.m.

New subject: cabal beginner issues (other-modules, build-depends)

Isaac Jones writes:

...

...
hmake certainly handles multi-line comments, and #ifdef'd conditional imports (by using cpphs as a library).

Great. I had some vague memories about HMake's parser for input statements being over simple, so I'm sorry I was incorrect there.

It /is/ rather simple-minded. But it doesn't really need to be complex, there are only a few odd corner cases where you need to be slightly careful.

...

...
I think the only thing not handled entirely correctly is several import statements on the same line separated by semicolons.

Actually I was wrong - this is already handled correctly. See http://haskell.org/hmake/bugs.html But in testing it, I did discover a different corner case that was wrong: module A where { import B -- this import was being missed due to leading { ; import C ; ... } Now fixed in CVS.

...

Cool. Maybe we can steal your code :)

Yeah, of course, provided you abide by the license (nhc98-style) - this use would fall under the definition of stealing < 10% of any one program. (But you should also be aware that the cpphs modules are LGPL.) Regards, Malcolm

7160

Age (days ago)

7179

Last active (days ago)

List overview

Download

6 comments

4 participants

participants (4)

Isaac Jones
Malcolm Wallace
Ross Paterson
Simon Marlow