Opened 2 years ago

Closed 2 years ago

Last modified 19 months ago

#9744 closed feature request (fixed)

Make program name and project version configurable

Reported by: luite Owned by: luite
Priority: normal Milestone: 8.0.1
Component: Compiler Version: 7.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D496
Wiki Page:


GHC uses cProjectVersion in a few places and ghc is hardcoded as the program name. This is used for example for determining the location of the user package database (getAppUserDataDirectory "ghc") and the names of dynamic libraries.

I've been working around this for GHCJS, but it requires copying quite a bit of code. I have a patch that adds the program name and version to Settings that I'll submit once I've tested GHCJS with HEAD.

My patch just allows these settings to be changed by GHC API clients. However, we could also make GHC itself read its own values from the settings file. This way we could add a version tag to a GHC installation without recompiling, keeping its packages and package databases separate from existing ones.

Let me know if there's any interest in this and I'll add it to the patch.

Change History (6)

comment:1 Changed 2 years ago by luite

Side note: Hardcoded constants are also used for the target platform, while the actual target is configurable through DynFlags/Settings. Unfortunately properly printing a platform triple appears to be a bit hairy. I don't need this for GHCJS, so I've left it out so far for this reason.

comment:2 Changed 2 years ago by thomie

Differential Rev(s): Phab:D496

comment:3 Changed 2 years ago by Austin Seipp <austin@…>

In 4523d669989ab3b08e360016a315d6f9cd4808b0/ghc:

trac #9744, make program name and product version configurable through DynFlags/Settings


This allows GHC API clients to use a package database and dynamic
library names that do not clash with those of the host GHC

This also updates the Haddock submodule.

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: thomie, carter

Differential Revision:

comment:4 Changed 2 years ago by thoughtpolice


Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:5 Changed 2 years ago by luite

Resolution: fixed
Status: newclosed

comment:6 Changed 19 months ago by thoughtpolice


Milestone renamed

Note: See TracTickets for help on using tickets.