Re: cabal sandboxes executable path

27 Dec 2013

      * Konstantine Rybnikov  [2013-12-27 08:21:39+0100]
...
On Fri, Dec 27, 2013 at 1:02 AM, Roman Cheplyaka  wrote:
...
* Tom Ellis  [2013-12-26 19:33:19+0000]
...
On Thu, Dec 26, 2013 at 08:18:40PM +0100, Konstantine Rybnikov wrote:
...
Wow, this is a real surprise for me! Thank for clarifying that!
I hope it's just me who missed this important information. Could you please
share where was it described and how people know about it?
This is a surprise to me too.  What's the difference between the executable
in 'dist' and the final one?   What happens if I just do 'cabal build'?  Is
the final one not actually built?
In that case the executable is built (and placed under dist/), just not
copied to the final destination (such as ~/.cabal/bin or .cabal-sandbox/bin).
This is much like traditional make && make install.
The problem here (for me at least) that they're different, it's not
just "copying". At least in size in my case (20mb and 30 mb, looks
like one is stripped, but what else?).
Yes, it's stripped. Nothing else at the moment, from what I can tell:

  installBinary dest = do
    installExecutableFile verbosity
      (buildPref  exeName exe  exeFileName)
      (dest <.> exeExtension)
    when (stripExes lbi) $
      Strip.stripExe verbosity (withPrograms lbi) (dest <.> exeExtension)

(Distribution/Simple/GHC.hs)
...
So it's strange that in one
case dist/ contains "temporary build file that differs from end-one",
and then (on build) it contains actual binary.
Not sure what you mean here. Stripping occurs after copying, in the
destination directory. The binary in dist/ is never stripped.
...
I think we should at least make sure the files are equal (do all steps
in dist/ and then copy binary), or, if this is not acceptable, at
least write a note about that everywhere :)
Can you explain why this matters?

Stripping on install makes perfect sense. dist/ should only be used for
development purposes, so we're saving some time by not stripping.

OTOH, `cabal install` is clearly for installation/deployment.

Again, this is consistent with what make and make install have been
doing for a long time.

(BTW, I don't think libraries@ is the right list for this discussion.
It's for discussing changes to the core libraries.
haskell-cafe would be a better choice.)

Roman