Johannes Waldmann writes:

Duncan Coutts writes:

...

Your .cabal file probably does not list the "other-modules" as it should, so Cabal does not know that the other modules exist.

Ah.

Strange though that it seems to be able to do lots of reasonable things (build the executable, build all the API docs) without this "other-modules" section.

The executable bit cheats: since it just calls "ghc --make Main.hs", GHC will bring in all the other modules. However, I don't think in general that those other modules will be included into the tarball in question since Cabal doesn't know to include them.

I figure it's a cabal design choice, but I don't see the reason for it.

Dependency resolution (for modules) isn't done by Cabal; you have to explicitly state it.

It seems it just forces me to construct manually some information that the machine already knows.

The machine doesn't know; GHC might know but the machine doesn't. And whilst it might be possible to have "cabal init" generate Other-Modules for you, you'd still have to keep it in sync somehow.

OK, we have the same thing for type or interface specifications (redundancy is good to detect programmer errors) but I don't see from what errors we need protection here.

What errors? You just have to somehow specify which files are being used by your package. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 18 August 2010 12:55, Johannes Waldmann wrote:

Duncan Coutts writes:

...

Your .cabal file probably does not list the "other-modules" as it should, so Cabal does not know that the other modules exist.

Ah.

Strange though that it seems to be able to do lots of reasonable things (build the executable, build all the API docs) without this "other-modules" section.

Right. It is required but not enforced. If you forget with executables then usually nothing horrible happens. If you forget with libraries then you end up with a broken library. Enforcing it properly is on the TODO list.

I figure it's a cabal design choice, but I don't see the reason for it.

In general it is impossible to use dependency chasing to automatically discover all the modules/files required by a lib/exe because of things like conditional compilation. You can find out what is needed for the current configuration for the current machine, but that does not help with preparing source distributions where e.g. you might have different modules for windows vs unix.

It seems it just forces me to construct manually some information that the machine already knows.

Almost, see above. Certainly we could check when the information provided is wrong (by Cabal doing the dependency chasing rather than leaving it for the tools like ghc --make or haddock). What we cannot check is if it is right. Duncan

On 18 August 2010 15:13, Johannes Waldmann wrote:

Duncan Coutts writes:

...

...

...

Your .cabal file probably does not list the "other-modules" ... Enforcing it properly is on the TODO list.

Please don't ... there's the design principle of "making the typical case easy, but the complicated case possible" (or something similar to that effect). It seems that you plan to make the typical case cumbersome.

Enforce is the wrong word. The more friendly thing is to tell users when the list is incomplete. As I mentioned before, in general it is necessary to list all the modules because in general it is impossible to discover them all automatically. Further, even when it is possible, there is value in not requiring all tools that process .cabal files to embed all the dependency chasing logic. Listing other modules also means we can discover the full set of modules without having to configure and build the package (in general it requires configuring the package, and then compiling and running preprocessors). Alternatively we could decide that we will allow users to specify other modules just for the cases where discovering all the modules is hard/impossible and then require all tools that handle .cabal files to contain the logic for dependency chasing. IMHO, the ideal is when cabal can mostly work without any .cabal file for simple programs and then provides help to make and maintain accurate .cabal files.

The question in this thread is about generating hscolourized source. Everything else is working fine already - haddock is run on all modules (in the transitive import closure - how is it computed?), it's just that hscolour is not run. I hoped there is an easy fix for that (= hack, if you want).

Actually, I don't need cabal here. Perhaps haddock should compute the module import closure (and then run hscolour)?

That would also work. That is independent of the need to list all modules in the .cabal file.

For reference, you don't need to list all source files here: http://download.oracle.com/javase/1.5.0/docs/tooldocs/windows/javadoc.html#p... singofsourcefiles

Right, if you do not have any preprocessing or conditional compilation then import chasing is relatively easy and will cover all modules. Duncan