#15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nomeata: Old description:

The GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded.

One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places:

* It is (of course) used a lot in rts. That’s fine. * It is used via tablesNextToCode :: DynFlags -> Bool in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there.

(The motivation is similar to #13477)

New description: The GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded. One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places: * It is (of course) used a lot in rts. That’s fine. * It is used via `tablesNextToCode :: DynFlags -> Bool` in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there. (The motivation is similar to #13477) -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15548#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5082 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): There is one curious spot left, in `SysTools` {{{ tntc_gcc_args | mkTablesNextToCode targetUnregisterised = ["-DTABLES_NEXT_TO_CODE"] | otherwise = [] cpp_args= map Option (words cpp_args_str) gcc_args = map Option (words gcc_args_str ++ unreg_gcc_args ++ tntc_gcc_args) }}} This sets the default C arguments based on the initial settings (not the dynflags). I am wondering if anything actually relies on GHC setting the flag here, especially since `/usr/lib/ghc/include/ghcautoconf.h`, included by various header files, _also_ sets `TABLES_NEXT_TO_CODE`. I guess I should just try it out. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15548#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler