Dual compiler support #3
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Don't enable -threaded unconditionnally when building Setup.hs. We may only have vanilla libraries (but maybe we don't have them either?) Revert ae0e752
The treatment of --executable-static means we pass `-optl-static` to GHC, which in turn just passes this to the linker. This flag can not work on macOS. Fully static linking is impossible as libSystem must be linked dynamically. Thus here we disable this flag for macOS.
This reverts b408167 in spirit from haskell#4656.
Run a program (named "preBuildHook") before doing a package build and another program (named "postBuildHook") after the package is built. The exit code from the pre-build hook is passed to the post-build hook. The commit includes documentation for the hooks and the security safeguards implemented to avoid the running of malicious hook files. (cherry picked from commit 5f7b47f)
This has to be cleaned up but it does not make sense to pass the compiler.
Remove QualifyOptions by setting qoSetupIndependent to be always true (the current default) and qoBaseShim false (this must have been just a hack of some sort).
principalPP and setupPP seem to have gone unused since 8194fab
I would need to rework packagesWithLibDepsDownwardClosedProperty. It has to be done but not now.
This reverts commit 5b81693.
This reverts commit c520482.
This patch is quite raw. - Effectively ComponentId and UnitId are very similar. I think UnitId should just be a newtype around ComponentId. - We have Partial IDs, which should really be called Legacy, as they deal with non-compiler-prefixed ids. - We need to modify the parsing of installed packages, to inject the compiler into unit-ids. - We also need to modify parsing configure flags (--dependency=...) to ensure the ids are aligned. Note: we need to support INTERNAL and EXTERNAL Setup.hs. (This shows up with --dependency=...) especially.
This came up when building a main-library-free package with `Setup.hs`.
This reverts commit 225c7a4.
This reverts commit db4f461.
When components were introduced, cabal had support for build-type: Configure, which allows to run a `configure` script prior to building the package. Upon the introduction of components, it became obvious that we can't just configure each and every component, as this easily runs into the situation where the `configure` script is run potentially concurrently for all components. However, build-type is a global option for cabal files, and is usually used to produce a <pkg>.buildinfo file. This file is then used to augment the Main Library only. This change now tracks whether or not we are building a component to the setup invocation, and if we do, ignores a build-type: Configure built-type from the package description. For end users who want to depend on package configured values, they will need to set their sub libraries, executables, ... and other components to depend on the main library, and import any configured values from there. For lib:Cabal, which doesn't know about components when configure is invoked, we will continue to execute configure, even though cabal will never use that info.
This reverts commit 07f4dd5.
When components were introduced, cabal had support for build-type: Configure, which allows to run a `configure` script prior to building the package. Upon the introduction of components, it became obvious that we can't just configure each and every component, as this easily runs into the situation where the `configure` script is run potentially concurrently for all components. However, build-type is a global option for cabal files, and is usually used to produce a <pkg>.buildinfo file. This file is then used to augment the Main Library and Executables only. This change now tracks whether or not we are building a main library or executable component, and if we do, retains only for these components the build-type: Configure from the package description. For all other components, we will fall back to the default build-type: Simple. For end users who want to depend on package configured values, they will need to set their sub libraries, testsuites and benchmark components to depend on the main library, and import any configured values from there. For lib:Cabal, which doesn't know about components when configure is invoked, we will continue to execute configure. There is no impact on lib:Cabal in this change.
Cabal uses a peculiar c program to check if LD supports and should use -x. To do this, it shells out to GHC to compiler the C file. This however requires that GHC will not bail out, yet cabal does not pass --package-db flags to this GHC invocation, and as such we can run into situations where GHC bails out, especially during GHC bootstrap phases where not all boot packages are available. We however do not need GHC to compiler a c program, and can rely on the C compiler. Fundamentally cabal does not allow modelling program dependencies in the program db, as such we must configure gcc first before using it. We make a small change to lib:Cabal (specifically the GHC module, and it's Internal companion) to allow it to configure gcc first, before trying to configure ld, and thus having gcc in scope while configuring ld. This removes the need for the awkward ghc invocation to compiler the test program.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.