[Git][ghc/ghc][wip/romes/enable-ghc-toolchain] 2 commits: Pass user-specified options to ghc-toolchain

Rodrigo Mesquita (@alt-romes) gitlab at gitlab.haskell.org
Tue Jul 18 17:41:59 UTC 2023



Rodrigo Mesquita pushed to branch wip/romes/enable-ghc-toolchain at Glasgow Haskell Compiler / GHC


Commits:
eaa026a2 by Rodrigo Mesquita at 2023-07-18T18:32:34+01:00
Pass user-specified options to ghc-toolchain

The current user interface to configuring target toolchains is `./configure`.

In !9263 we added a new tool to configure target toolchains called
`ghc-toolchain`, but the blessed way of creating these toolchains is
still through configure.

However, we were not passing the user-specified options given with the
`./configure` invocation to the ghc-toolchain tool.

This commit remedies that by storing the user options and environment
variables in USER_* variables, which then get passed to GHC-toolchain.

The exception to the rule is the windows bundled toolchain, which
overrides the USER_* variables with whatever flags the windows bundled
toolchain requires to work.
We consider the bundled toolchain to be effectively the user specifying
options, since the actual user delegated that configuration work.

Closes #23678

- - - - -
695a74ab by Rodrigo Mesquita at 2023-07-18T18:41:45+01:00
Let's look at CI for #23681

- - - - -


6 changed files:

- configure.ac
- m4/fp_cpp_cmd_with_args.m4
- m4/fp_hs_cpp_cmd_with_args.m4
- m4/fp_setup_windows_toolchain.m4
- m4/ghc_toolchain.m4
- utils/ghc-toolchain/src/GHC/Toolchain/Tools/Cc.hs


Changes:

=====================================
configure.ac
=====================================
@@ -42,6 +42,15 @@ dnl works as expected, since we're slightly modifying how Autoconf
 dnl interprets build/host/target and how this interacts with $CC tests
 test -n "$target_alias" && ac_tool_prefix=$target_alias-
 
+dnl ----------------------------------------------------------
+dnl ** Store USER specified environment variables to pass them on to
+dnl ** ghc-toolchain (in m4/ghc-toolchain.m4)
+USER_CFLAGS="$CFLAGS"
+USER_LDFLAGS="$LDFLAGS"
+USER_LIBS="$LIBS"
+USER_CXXFLAGS="$CXXFLAGS"
+
+
 dnl ----------------------------------------------------------
 dnl ** Find unixy sort and find commands,
 dnl ** which are needed by FP_SETUP_PROJECT_VERSION
@@ -167,7 +176,7 @@ AC_ARG_ENABLE(ghc-toolchain,
 [AS_HELP_STRING([--enable-ghc-toolchain],
                 [Whether to use the newer ghc-toolchain tool to configure ghc targets])],
   [FP_CAPITALIZE_YES_NO(["$enableval"], [EnableGhcToolchain])],
-  [EnableGhcToolchain=NO]
+  [EnableGhcToolchain=YES]
 )
 AC_SUBST([EnableGhcToolchain])
 


=====================================
m4/fp_cpp_cmd_with_args.m4
=====================================
@@ -45,6 +45,7 @@ AC_ARG_WITH(cpp-flags,
       # Use whatever flags were manually set, ignoring previously configured
       # flags; and add CPP_ARGS (which will be -E if CPP_CMD was not specified)
       CPP_ARGS="$CPP_ARGS $withval"
+      USER_CPP_ARGS="$withval"
   fi
 ],
 [


=====================================
m4/fp_hs_cpp_cmd_with_args.m4
=====================================
@@ -39,6 +39,7 @@ AC_ARG_WITH(hs-cpp-flags,
           AC_MSG_WARN([Request to use $withval will be ignored])
       else
           HS_CPP_ARGS=$withval
+          USER_HS_CPP_ARGS=$withval
       fi
   ],
 [


=====================================
m4/fp_setup_windows_toolchain.m4
=====================================
@@ -127,4 +127,13 @@ AC_DEFUN([FP_SETUP_WINDOWS_TOOLCHAIN],[
     MergeObjsCmd=""
     MergeObjsArgs=""
     AC_PATH_PROG([Genlib],[genlib])
+
+
+    dnl We override the USER_* flags here since the user delegated
+    dnl configuration to the bundled windows toolchain, and these are the
+    dnl options required by the bundled windows toolchain.
+    USER_CFLAGS="$CFLAGS"
+    USER_CXXFLAGS="$CXXFLAGS"
+    USER_HS_CPP_ARGS="$HaskellCPPArgs"
+    USER_LDFLAGS="$CONF_GCC_LINKER_OPTS_STAGE2"
 ])


=====================================
m4/ghc_toolchain.m4
=====================================
@@ -76,6 +76,7 @@ AC_DEFUN([FIND_GHC_TOOLCHAIN],
     # the usual system locations, including the PATH, we are just explicit when
     # calling it through configure.
     rm -f acargs
+
     echo "--triple=$target" >> acargs
     echo "--output=$1/default.target.ghc-toolchain" >> acargs
     echo "--llvm-triple=$LlvmTarget" >> acargs
@@ -90,9 +91,20 @@ AC_DEFUN([FIND_GHC_TOOLCHAIN],
     echo "--merge-objs=$MergeObjsCmd" >> acargs
     echo "--readelf=$READELF" >> acargs
     echo "--windres=$WindresCmd" >> acargs
+
     ENABLE_GHC_TOOLCHAIN_NOT_ARG([locally-executable], [$CrossCompiling])
     ENABLE_GHC_TOOLCHAIN_ARG([unregisterised], [$Unregisterised])
     ENABLE_GHC_TOOLCHAIN_ARG([tables-next-to-code], [$TablesNextToCode])
+    ENABLE_GHC_TOOLCHAIN_ARG([ld-override], [$enable_ld_override])
+    ENABLE_GHC_TOOLCHAIN_ARG([libffi-adjustors], [$UseLibffiForAdjustors])
+
+    dnl We store USER_* variants of all user-specified flags to pass them over to ghc-toolchain.
+    ADD_GHC_TOOLCHAIN_ARG([cc-opt], [$USER_CFLAGS])
+    ADD_GHC_TOOLCHAIN_ARG([cc-link-opt], [$USER_LDFLAGS])
+    ADD_GHC_TOOLCHAIN_ARG([cc-link-opt], [$USER_LIBS])
+    ADD_GHC_TOOLCHAIN_ARG([cxx-opt], [$USER_CXXFLAGS])
+    ADD_GHC_TOOLCHAIN_ARG([cpp-opt], [$USER_CPP_ARGS])
+    ADD_GHC_TOOLCHAIN_ARG([hs-cpp-opt], [$USER_HS_CPP_ARGS])
 
     INVOKE_GHC_TOOLCHAIN()
 


=====================================
utils/ghc-toolchain/src/GHC/Toolchain/Tools/Cc.hs
=====================================
@@ -37,21 +37,7 @@ findCc :: String -- ^ The llvm target to use if Cc supports --target
 findCc llvmTarget progOpt = checking "for C compiler" $ do
     -- TODO: We keep the candidate order we had in configure, but perhaps
     -- there's a more optimal one
-    ccProgram' <- findProgram "C compiler" progOpt ["gcc", "clang", "cc"]
-
-    -- FIXME: This is a dreadful hack!
-    -- In reality, configure should pass these options to ghc-toolchain when
-    -- using the bundled windows toolchain, and ghc-toolchain should drop this around.
-    -- See #23678
-    let ccProgram = if "mingw32" `isInfixOf` llvmTarget && takeBaseName (prgPath ccProgram') == "clang"
-                    -- we inline the is-windows check here because we need Cc to call parseTriple
-         then
-           -- Signal that we are linking against UCRT with the _UCRT macro. This is
-           -- necessary on windows clang to ensure correct behavior when
-           -- MinGW-w64 headers are in the header include path (#22159).
-           ccProgram' & _prgFlags %++ "--rtlib=compiler-rt -D_UCRT"
-         else
-           ccProgram'
+    ccProgram <- findProgram "C compiler" progOpt ["gcc", "clang", "cc"]
 
     cc' <- ignoreUnusedArgs $ Cc {ccProgram}
     cc  <- ccSupportsTarget llvmTarget cc'



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e9a3ff5b995e39fe5b10139060954f7f8e36f2b6...695a74abbb0a6e55c4c2b01e7effff7c0ba5a768

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e9a3ff5b995e39fe5b10139060954f7f8e36f2b6...695a74abbb0a6e55c4c2b01e7effff7c0ba5a768
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230718/26e4c28b/attachment-0001.html>


More information about the ghc-commits mailing list