Skip to content

Dual compiler support #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 94 commits into
base: master
Choose a base branch
from
Open

Dual compiler support #3

wants to merge 94 commits into from

Conversation

angerman
Copy link

No description provided.

andreabedini and others added 30 commits March 18, 2025 13:08
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.
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.
angerman added 30 commits March 26, 2025 11:47
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`.
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.
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants