Changes between Version 2 and Version 3 of Plugins/ReinitializeGlobals


Ignore:
Timestamp:
Jul 4, 2013 10:05:00 PM (23 months ago)
Author:
nfrisby
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins/ReinitializeGlobals

    v2 v3  
    55=== !CoreMonad.reinitializeGlobals === 
    66 
    7 For unfortunate reasons I don't fully understand (#5355, #5292), the host compiler and plugins have distinct copies of global variables. The current workaround is `CoreMonad.reinitializeGlobals`, which every plugin is supposed to call at the beginning of its `install` routine. This function overwrites the plugin's global variables with the corresponding values of the host compiler's. It requires a little plumbing to pull make this work but not much, and the plugin author sees only `reinitializeGlobals`. 
     7For unfortunate reasons I don't fully understand (#5355, #5292), the host compiler and plugins have distinct copies of global variables (unless the host compiler dynamically loads libHSghc, eg on Windows; see the next section).  The current workaround is `CoreMonad.reinitializeGlobals`, which every plugin is supposed to call at the beginning of its `install` routine.  This function overwrites the plugin's global variables with the corresponding values of the host compiler's. It requires a little plumbing to make this work but not much, and the plugin author sees only `reinitializeGlobals`. 
    88 
    99The long-term plan is to eventually totally avoid having two separate images of the ghc library and then redefine `reinitializeGlobals = return ()`. 
     
    3030# particular, this means that GHCi will use DLLs rather than loading 
    3131# object files directly. 
    32 ifeq "$(TargetOS_CPP)" "mingw32" 
     32ifeq "$(TargetOS_CPP)" "mingw32"                     # <---- this means Windows 
    3333# This doesn't work on Windows yet 
    3434DYNAMIC_GHC_PROGRAMS = NO