Re: Linking executables and the library of a Cabal package description

On Wed, 2007-10-17 at 09:07 -0400, John D. Ramsdell wrote:

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