Linking executables and the library of a Cabal package description

[John D. Ramsdell]

Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:

> > 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