[GHC] #14793: some executables in the binary distribution are not versioned
GHC
ghc-devs at haskell.org
Sun Feb 11 23:36:39 UTC 2018
#14793: some executables in the binary distribution are not versioned
-------------------------------------+-------------------------------------
Reporter: dmwit | Owner: (none)
Type: feature | Status: new
request |
Priority: normal | Milestone:
Component: Build System | Version: 8.2.2
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
GHC is generally quite careful to play nicely when you install multiple
versions, in particular by putting a version number somewhere in the
filepath for almost every installed file. Then a few top-level non-
versioned symlinks are made to (versioned) executables. Consequently,
build tools with enough knowledge of the GHC versioning infrastructure can
select an older or newer GHC to build things with by ignoring the top-
level symlinks and explicitly selecting the versioned executable names.
There are a few exceptions where this is not possible: hsc2hs, hp2ps, and
hpc. These executables are *overwritten* on each installation, so it is
not possible to select "the one that goes with the currently chosen
compiler".
I'd like to request that these begin being installed with the same scheme
as other GHC executables: with an appended dash and version number,
together with a non-versioned symlink.
I don't know to what extent this matters for hp2ps and hpc; perhaps these
change infrequently enough that it doesn't matter too much. But hsc2hs at
least bakes some GHC version knowledge in; it has at least a default
template that it #include's that defines some C macros, and this template
changes occasionally. There is a command-line option to specify a template
filepath explicitly, but it would be nice if build tools could reliably
choose a version of hsc2hs that has the right defaults, so that using the
command-line flag is a special case for special circumstances.
(For some context: I have just finished hunting down an issue related to
exactly this. I installed an older GHC to test that some code was
backwards-compatible. All of a sudden, existing builds, still using the
new compiler, started failing, because hsc2hs was now using an outdated
template that did not define all the necessary macros.)
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14793>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list