[Git][ghc/ghc][master] 2 commits: Fix use distro toolchian
Marge Bot
gitlab at gitlab.haskell.org
Fri Aug 28 06:23:19 UTC 2020
Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC
Commits:
f065b6b0 by Tamar Christina at 2020-08-28T02:23:13-04:00
Fix use distro toolchian
- - - - -
4517a382 by Tamar Christina at 2020-08-28T02:23:13-04:00
document how build system find toolchains on Windows
- - - - -
10 changed files:
- aclocal.m4
- compiler/GHC/SysTools/BaseDir.hs
- configure.ac
- hadrian/cfg/system.config.in
- hadrian/src/Oracles/Flag.hs
- hadrian/src/Oracles/Setting.hs
- hadrian/src/Rules/Generate.hs
- includes/ghc.mk
- mk/config.mk.in
- mk/project.mk.in
Changes:
=====================================
aclocal.m4
=====================================
@@ -507,6 +507,7 @@ AC_DEFUN([GET_ARM_ISA],
# FP_SETTINGS
# ----------------------------------
# Set the variables used in the settings file
+# See Note [tooldir: How GHC finds mingw on Windows]
AC_DEFUN([FP_SETTINGS],
[
if test "$windows" = YES -a "$EnableDistroToolchain" = "NO"
@@ -583,6 +584,7 @@ AC_DEFUN([FP_SETTINGS],
SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2"
SettingsCCompilerSupportsNoPie="$CONF_GCC_SUPPORTS_NO_PIE"
SettingsLdFlags="$CONF_LD_LINKER_OPTS_STAGE2"
+ SettingsUseDistroMINGW="$EnableDistroToolchain"
AC_SUBST(SettingsCCompilerCommand)
AC_SUBST(SettingsHaskellCPPCommand)
AC_SUBST(SettingsHaskellCPPFlags)
@@ -601,6 +603,7 @@ AC_DEFUN([FP_SETTINGS],
AC_SUBST(SettingsClangCommand)
AC_SUBST(SettingsLlcCommand)
AC_SUBST(SettingsOptCommand)
+ AC_SUBST(SettingsUseDistroMINGW)
])
# Helper for cloning a shell variable's state
=====================================
compiler/GHC/SysTools/BaseDir.hs
=====================================
@@ -34,16 +34,6 @@ import System.FilePath
import System.Directory (doesDirectoryExist)
#endif
-#if defined(mingw32_HOST_OS)
-# if defined(i386_HOST_ARCH)
-# define WINDOWS_CCONV stdcall
-# elif defined(x86_64_HOST_ARCH)
-# define WINDOWS_CCONV ccall
-# else
-# error Unknown mingw32 arch
-# endif
-#endif
-
{-
Note [topdir: How GHC finds its files]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -70,16 +60,89 @@ Note [tooldir: How GHC finds mingw on Windows]
GHC has some custom logic on Windows for finding the mingw
toolchain and perl. Depending on whether GHC is built
with the make build system or Hadrian, and on whether we're
-running a bindist, we might find the mingw toolchain and perl
+running a bindist, we might find the mingw toolchain
either under $topdir/../{mingw, perl}/ or
$topdir/../../{mingw, perl}/.
+This story is long and with lots of twist and turns.. But lets talk about how
+the build system finds and wires through the toolchain information.
+
+1) It all starts in configure.ac which has two modes it operates on:
+ a) The default is where `EnableDistroToolchain` is false. This indicates
+ that we want to use the in-tree bundled toolchains. In this mode we will
+ download and unpack some custom toolchains into the `inplace/mingw` folder
+ and everything is pointed to that folder.
+ b) The second path is when `EnableDistroToolchain` is true. This makes the
+ toolchain behave a lot like Linux, in that the environment is queried for
+ information on the tools we require.
+
+ From configure.ac we export the standard variables to set the paths to the
+ tools for the build system to use.
+
+2) After we have the path to the tools we have to generate the right paths to
+ store in the settings file for ghc to use. This is done in aclocal.m4.
+ Again we have two modes of operation:
+ a) If not `EnableDistroToolchain` the paths are rewritten to paths using a
+ variable `$tooldir` as we need an absolute path. $tooldir is filled in by
+ the `expandToolDir` function in this module at GHC startup.
+ b) When `EnableDistroToolchain` then instead of filling in a absolute path
+ we fill in just the program name. The assumption here is that at runtime
+ the environment GHC is operating on will be the same as the one configure
+ was run in. This means we expect `gcc, ld, as` etc to be on the PATH.
+
+ From `aclocal.m4` we export a couple of variables starting with `Settings`
+ which will be used to generate the settings file.
+
+3) The next step is to generate the settings file, this is where things diverge
+ based on the build system. Both Make and Hadrian handle this differently:
+
+make)
+ Make deals with this rather simply. As an output of configure.ac
+ `config.mk.in` is processed and `config.mk` generated which has the values we
+ set in `aclocal.m4`. This allows the rest of the build system to have access
+ to these and other values determined by configure.
+
+ Based on this file, `includes/ghc.mk` when ran will produce the settings file
+ by echoing the values into a the final file. Coincidentally this is also
+ where `ghcplatform.h` and `ghcversion.h` generated which contains information
+ about the build platform and sets CPP for use by the entire build.
+
+hadrian)
+ For hadrian the file `cfg/system.config.in` is preprocessed by configure and
+ the output written to `system.config`. This serves the same purpose as
+ `config.mk` but it rewrites the values that were exported. As an example
+ `SettingsCCompilerCommand` is rewritten to `settings-c-compiler-command`.
+
+ Next up is `src/Oracles/Settings.hs` which makes from some Haskell ADT to
+ the settings `keys` in the `system.config`. As an example,
+ `settings-c-compiler-command` is mapped to
+ `SettingsFileSetting_CCompilerCommand`.
+
+ The last part of this is the `generateSettings` in `src/Rules/Generate.hs`
+ which produces the desired settings file out of Hadrian. This is the
+ equivalent to `includes/ghc.mk`.
+
+--
+
+So why do we have these? On Windows there's no such thing as a platform compiler
+and as such we need to provide GCC and binutils. The easiest way is to bundle
+these with the compiler and wire them up. This gives you a relocatable
+binball. This works fine for most users. However mingw-w64 have a different
+requirement. They require all packages in the repo to be compiled using the
+same version of the compiler. So it means when they are rebuilding the world to
+add support for GCC X, they expect all packages to have been compiled with GCC X
+which is a problem since we ship an older GCC version.
+
+GHC is a package in mingw-w64 because there are Haskell packages in the
+repository which of course requires a Haskell compiler. To help them we
+provide the override which allows GHC to instead of using an inplace compiler to
+play nice with the system compiler instead.
-}
-- | Expand occurrences of the @$tooldir@ interpolation in a string
-- on Windows, leave the string untouched otherwise.
expandToolDir :: Maybe FilePath -> String -> String
-#if defined(mingw32_HOST_OS)
+#if defined(mingw32_HOST_OS) && !defined(USE_INPLACE_MINGW_TOOLCHAIN)
expandToolDir (Just tool_dir) s = expandPathVar "tooldir" tool_dir s
expandToolDir Nothing _ = panic "Could not determine $tooldir"
#else
@@ -113,14 +176,15 @@ tryFindTopDir Nothing
Nothing -> getBaseDir
--- See Note [tooldir: How GHC finds mingw and perl on Windows]
+-- See Note [tooldir: How GHC finds mingw on Windows]
-- Returns @Nothing@ when not on Windows.
-- When called on Windows, it either throws an error when the
-- tooldir can't be located, or returns @Just tooldirpath at .
+-- If the distro toolchain is being used we treat Windows the same as Linux
findToolDir
:: FilePath -- ^ topdir
-> IO (Maybe FilePath)
-#if defined(mingw32_HOST_OS)
+#if defined(mingw32_HOST_OS) && !defined(USE_INPLACE_MINGW_TOOLCHAIN)
findToolDir top_dir = go 0 (top_dir </> "..")
where maxDepth = 3
go :: Int -> FilePath -> IO (Maybe FilePath)
=====================================
configure.ac
=====================================
@@ -435,6 +435,7 @@ set_up_tarballs() {
fi
}
+# See Note [tooldir: How GHC finds mingw on Windows]
if test "$HostOS" = "mingw32" -a "$EnableDistroToolchain" = "NO"
then
test -d inplace || mkdir inplace
@@ -455,6 +456,7 @@ fi
# We don't want to bundle a MinGW-w64 toolchain
# So we have to find these individual tools.
+# See Note [tooldir: How GHC finds mingw on Windows]
if test "$EnableDistroToolchain" = "YES"
then
# Ideally should use AC_CHECK_TARGET_TOOL but our triples
@@ -462,6 +464,7 @@ then
# so never tried without the prefix.
AC_PATH_PROG([CC],[gcc], [clang])
AC_PATH_PROG([NM],[nm])
+ AC_PATH_PROG([LD],[ld])
AC_PATH_PROG([AR],[ar])
AC_PATH_PROG([RANLIB],[ranlib])
AC_PATH_PROG([OBJDUMP],[objdump])
=====================================
hadrian/cfg/system.config.in
=====================================
@@ -92,6 +92,8 @@ project-patch-level1 = @ProjectPatchLevel1@
project-patch-level2 = @ProjectPatchLevel2@
project-git-commit-id = @ProjectGitCommitId@
+system-use-distro-mingw = @SettingsUseDistroMINGW@
+
# Compilation and linking flags:
#===============================
@@ -127,6 +129,7 @@ conf-merge-objects-args-stage3 = @SettingsMergeObjectsFlags@
# We are in the process of moving the settings file from being entirely
# generated by configure, to generated being by the build system. Many of these
# might become redundant.
+# See Note [tooldir: How GHC finds mingw on Windows]
gcc-extra-via-c-opts = @GccExtraViaCOpts@
ld-has-no-compact-unwind = @LdHasNoCompactUnwind@
=====================================
hadrian/src/Oracles/Flag.hs
=====================================
@@ -25,6 +25,7 @@ data Flag = ArSupportsAtFile
| HaveLibMingwEx
| UseSystemFfi
| BootstrapThreadedRts
+ | SystemDistroMINGW
-- Note, if a flag is set to empty string we treat it as set to NO. This seems
-- fragile, but some flags do behave like this.
@@ -45,6 +46,7 @@ flag f = do
HaveLibMingwEx -> "have-lib-mingw-ex"
UseSystemFfi -> "use-system-ffi"
BootstrapThreadedRts -> "bootstrap-threaded-rts"
+ SystemDistroMINGW -> "system-use-distro-mingw"
value <- lookupValueOrError configFile key
when (value `notElem` ["YES", "NO", ""]) . error $ "Configuration flag "
++ quote (key ++ " = " ++ value) ++ " cannot be parsed."
=====================================
hadrian/src/Oracles/Setting.hs
=====================================
@@ -184,6 +184,7 @@ settingList key = fmap words $ lookupValueOrError configFile $ case key of
-- | Look up the value of a 'SettingList' in @cfg/system.config@, tracking the
-- result.
+-- See Note [tooldir: How GHC finds mingw on Windows]
settingsFileSetting :: SettingsFileSetting -> Action String
settingsFileSetting key = lookupValueOrError configFile $ case key of
SettingsFileSetting_CCompilerCommand -> "settings-c-compiler-command"
=====================================
hadrian/src/Rules/Generate.hs
=====================================
@@ -245,6 +245,7 @@ generateGhcPlatformH = do
hostOs <- chooseSetting HostOs TargetOs
hostVendor <- chooseSetting HostVendor TargetVendor
ghcUnreg <- getFlag GhcUnregisterised
+ inplaceTools <- getFlag SystemDistroMINGW
return . unlines $
[ "#if !defined(__GHCPLATFORM_H__)"
, "#define __GHCPLATFORM_H__"
@@ -274,12 +275,15 @@ generateGhcPlatformH = do
, ""
]
++
+ [ "#define USE_INPLACE_MINGW_TOOLCHAIN 1" | inplaceTools ]
+ ++
[ "#define UnregisterisedCompiler 1" | ghcUnreg ]
++
[ ""
, "#endif /* __GHCPLATFORM_H__ */"
]
+-- See Note [tooldir: How GHC finds mingw on Windows]
generateSettings :: Expr String
generateSettings = do
ctx <- getContext
=====================================
includes/ghc.mk
=====================================
@@ -186,6 +186,9 @@ $$(includes_$1_H_PLATFORM) : includes/ghc.mk includes/Makefile | $$$$(dir $$$$@)
@echo "#define BUILD_VENDOR \"$(BuildVendor_$1_CPP)\"" >> $$@
@echo "#define HOST_VENDOR \"$(HostVendor_$1_CPP)\"" >> $$@
@echo >> $$@
+ifeq "$$(SettingsUseDistroMINGW)" "YES"
+ @echo "#define USE_INPLACE_MINGW_TOOLCHAIN 1" >> $$@
+endif
ifeq "$$(GhcUnregisterised)" "YES"
@echo "#define UnregisterisedCompiler 1" >> $$@
endif
@@ -204,6 +207,7 @@ $(eval $(call includesHeaderPlatform,1))
# These settings are read by GHC at runtime, so as to not cause spurious
# rebuilds.
+# See Note [tooldir: How GHC finds mingw on Windows]
includes_SETTINGS = includes/dist/build/settings
=====================================
mk/config.mk.in
=====================================
@@ -475,6 +475,7 @@ endif
# We are in the process of moving the settings file from being entirely
# generated by configure, to generated being by the build system. Many of these
# might become redundant.
+# See Note [tooldir: How GHC finds mingw on Windows]
GccExtraViaCOpts = @GccExtraViaCOpts@
LdHasFilelist = @LdHasFilelist@
=====================================
mk/project.mk.in
=====================================
@@ -20,8 +20,8 @@
#
# The ProjectVersionInt is included in interface files, and GHC
# checks that it's reading interface generated by the same ProjectVersion
-# as itself. It does this even though interface file syntax may not
-# change between versions. Rationale: calling conventions or other
+# as itself. It does this even though interface file syntax may not
+# change between versions. Rationale: calling conventions or other
# random .o-file stuff might change even if the .hi syntax doesn't
ProjectName = @ProjectName@
@@ -127,6 +127,7 @@ BuildVendor_CPP = @BuildVendor_CPP@
# Valid options: YES/NO
#
LeadingUnderscore=@LeadingUnderscore@
+SettingsUseDistroMINGW=@SettingsUseDistroMINGW@
# Pin a suffix on executables? If so, what (Windows only).
exeext0=@exeext_host@
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c6f50cea42a9ffc947bf4243986663cc820b0ec8...4517a38215eb72a4824c72d97377b9325059bf55
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c6f50cea42a9ffc947bf4243986663cc820b0ec8...4517a38215eb72a4824c72d97377b9325059bf55
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/20200828/32c69a3e/attachment-0001.html>
More information about the ghc-commits
mailing list