Non-package for sharing object file builds between multiple executables in same project

[BartMassey]

This bug is essentially a continuation of #81, which is in turn a continuation of Trac #89. As far as I can tell, in spite of the "fixed" resolution of #81, the underlying issue was never actually fixed.

Imagine that you have a package P with two executables A and B. Both of them use module M, also part of the project, but useless to anyone else. Currently, the only ways I know of to describe this situation to Cabal are:

• Specify a library L containing M. Unfortunately, this will cause Cabal to install L when P is installed, even though M is just useless noise.
• Specify M in the other-modules section of both A and B. Now M will be compiled twice. Occasionally, this recompilation may be a feature that allows different flags to be used for different executables, but by far the normal case is that it is just a waste of time. There may be many such modules (sometimes dozens and occasionally hundreds), so this seems to me like a problem worth fixing.

Possible fixes include allowing specifying that a library is private to a project, or allowing a new kind of section for common module description.

I wish that I had the Cabal skills to work on this, but I don't think I do.

[ezyang]

If the executables are dynamically linked, it is NOT a waste of time to install the library L: the shared library has to be installed somewhere! Perhaps what you are objecting to is the installation into the package database (which lets GHC know about the library), which would be unnecessary in this case because the libraries will always get built inplace, so perhaps this is #269?

[BartMassey]

I am normally perfectly happy to have module M and its brethren separately statically linked with A and B. I sometimes want to fully statically link executables anyhow, so that I can deliver them to non-Haskell-equipped systems.

That said, yes, #269 would probably solve the problem for me. Thanks for the pointer!

Like one of the commenters on Trac #89, I'm just frustrated that "make" is looking better than "cabal" in this use case right now.

[ezyang]

OK, I'll close this ticket in favor of the other one, and make sure #269 doesn't get closed :)