Duncan Coutts
If you add . to the Hs-Source-Dirs, you build module A twice, once for the library, and once for the building of b. Notice b is not linked with the library.
Correct.
There is a design choice here. If you link with the library you cannot use private modules.
That's good. I would expect you cannot use the private modules. Otherwise, they wouldn't be very private! One of the points of linking against the library is to ensure clients have access to only the exposed modules.
If you go direct to the source you can use anything but have to build twice.
This is obviously not what anyone would want.
To link with the lib, use a separate .cabal file that has an executable.
This is obviously not what one wants. The executables and the library are conceptually part of the same unit of code. At the very least, the Cabal documentation should up front about this design choice. The text surrounding Example 3 in Section 2 should explain that the generated library is not used to build the executables in the package. Having said all of that, are you sure there is not something I can add to get the behavior I'm looking for? In the real application, the library sources are in src/lib, and one of the executables is in src/basic. Cabal builds the library in dist/build, and builds the executable in dist/build/basic. It seems that everything needed for linking with every executable in my package is in its parent directory. Perhaps the stanza describing an executable has to contain a property for extra-lib-dirs, extra-libraries, or something about includes. Shouldn't I be able to tell the linker for an executable to look in parent of its build directory? John