Linking executables and the library of a Cabal package description

[Duncan Coutts]

On Wed, 2007-10-17 at 09:07 -0400, John D. Ramsdell wrote:
> 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.

It is exactly what some people want for test programs. They want to be
able to access the private modules to test functions that are not
exposed in the library public api.

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

They can't share a build directory since there's nothing that says that
they build the same modules using the same build flags. you could try
and hack it but I wouldn't recommend it.

The right way to solve this is to only allow a single library or
executable in a package and to make it possible to have multiple .cabal
files in a directory. Then they can describe components that may depend
on each other and we should be able to build the dependent components
automatically.

Then it's possible to either make an executable that depend on the
library, or to make one that uses the modules directly.

Duncan