Skip to content

Conversation

angerman
Copy link

No description provided.

hsyl20 and others added 4 commits August 28, 2025 22:16
This commit introduces a comprehensive cabal-based build infrastructure
to support multi-target and cross-compilation scenarios for GHC. The new
build system provides a clean separation between different build stages
and better modularity for toolchain components.

Key changes:
- Add Makefile with stage1, stage2, and stage3 build targets
- Create separate cabal.project files for each build stage
- Update configure.ac for new build system requirements
- Adapt hie.yaml to support cabal-based builds
- Update GitHub CI workflow for new build process

Build stages explained:
- Stage 1: Bootstrap compiler built with system GHC
- Stage 2: Intermediate compiler built with Stage 1
- Stage 3: Final compiler built with Stage 2 (for validation)

This modular approach enables:
- Clean cross-compilation support
- Better dependency management
- Simplified build process for different targets
- Improved build reproducibility

Contributors:
- Andrea Bedini: Build system design and Makefile implementation
- Moritz Angermann: Cross-compilation infrastructure

The new build system maintains compatibility with existing workflows
while providing a more maintainable foundation for future enhancements.
This commit restructures the Runtime System (RTS) components for better
modularity and reusability across different build configurations. The
changes enable cleaner separation of concerns and improved support for
cross-compilation scenarios.

Key changes:
- Extract RTS headers into standalone rts-headers package
  * Moved include/rts/Bytecodes.h to rts-headers
  * Moved include/rts/storage/ClosureTypes.h to rts-headers
  * Moved include/rts/storage/FunTypes.h to rts-headers
  * Moved include/stg/MachRegs/* to rts-headers
- Create rts-fs package for filesystem utilities
  * Extracted filesystem code from utils/fs
  * Provides reusable filesystem operations for RTS
- Rename utils/iserv to utils/ghc-iserv for consistency
  * Better naming alignment with other GHC utilities
  * Updated all references throughout the codebase
- Update RTS configuration and build files
  * Modified rts/configure.ac for new structure
  * Updated rts.cabal with new dependencies
  * Adjusted .gitignore for new artifacts

Rationale:
The modularization allows different stages of the compiler build to
share common RTS components without circular dependencies. This is
particularly important for:
- Cross-compilation where host and target RTS differ
- JavaScript backend which needs selective RTS components
- Stage1/Stage2 builds that require different RTS configurations

Contributors:
- Moritz Angermann: RTS modularization architecture and implementation
- Sylvain Henry: JavaScript backend RTS adjustments
- Andrea Bedini: Build system integration

This refactoring maintains full backward compatibility while providing
a cleaner foundation for multi-target support.
This commit completes the multi-target support infrastructure with
comprehensive changes across the compiler, build system, and runtime
components. These changes enable GHC to efficiently target multiple
platforms including native, JavaScript, and cross-compilation scenarios.

Core Compiler Changes:
- GHC.Driver.DynFlags: Multi-target configuration support
- GHC.Driver.Session: Enhanced session management for targets
- GHC.Driver.Make: Updated build orchestration for stages
- GHC.Driver.Downsweep: Improved module dependency handling
- GHC.ByteCode.Asm: Cross-platform bytecode assembly
- GHC.Iface.Load: Added Hooks parameter for interface loading
- GHC.Unit.State: Multi-target package database handling

LLVM Integration:
- GHC.CmmToLlvm.*: Refactored LLVM backend configuration
- Removed Version/Bounds.hs.in template
- Dynamic LLVM version detection
- Improved LLVM toolchain integration

JavaScript Backend:
- GHC.Driver.Config.StgToJS: JavaScript code generation config
- Enhanced JavaScript runtime support
- Integration with multi-stage build system

Linker and Code Generation:
- GHC.Linker.Dynamic: Cross-platform dynamic linking
- GHC.Linker.Static: Static linking improvements
- GHC.Linker.ExtraObj: Object file handling
- GHC.Driver.CodeOutput: Multi-target code emission
- CodeGen.Platform.h: Platform-specific code generation

Build System:
- ghc-pkg: Added --target flag support
- deriveConstants: Cross-compilation aware
- genprimopcode: Target-specific primop generation
- Setup.hs files: Updated for new build infrastructure
- packages: Updated submodule references

Libraries:
- system-cxx-std-lib: New C++ standard library wrapper
- ghc-internal: Updated configuration
- ghc-boot: Build system adjustments
- ghc-prim: Cross-compilation support

Testing Infrastructure:
- Updated test driver for multi-target scenarios
- Fixed platform-specific tests
- Adjusted test expectations for new architecture
- Added T10279h.hs test helper

External Dependencies:
- Removed libffi-tarballs (using system packages)
- Updated Cabal submodule
- Updated hsc2hs for cross-compilation

Utilities:
- unlit: Cross-platform compatibility
- ghc-toolchain: Target detection improvements
- config.guess/config.sub: GNU config files for RTS
- Added .envrc for development environment
- Added configure script for build configuration

Contributors:
- Moritz Angermann: Multi-target architecture and cross-compilation
- Sylvain Henry: JavaScript backend integration
- Andrea Bedini: Build system improvements
- Julian Ospald: Testing infrastructure and utilities

This completes the foundational work for GHC's multi-target support,
enabling efficient compilation for diverse platforms while maintaining
backward compatibility and build reproducibility.
Stable Haskell Team and others added 5 commits August 30, 2025 13:20
Boot: introduce ghc-boot-th-next for stage1 Template Haskell bootstrapping

Motivation:
Rebasing onto the 9.14 release branch exposed ordering / dependency
issues around Note [Bootstrapping Template Haskell] (see
GHC.Tc.Gen.Splice). We need a stage1 view of the TH AST (via
ghc-internal sources) without dragging the final ghc-boot-th package
shape (and its transitive deps) prematurely into the bootstrap set.

Overview:
We add a synthetic package ghc-boot-th-next, a copy of ghc-boot-th
(with name & self-references rewritten) used only in stage1 builds
(+bootstrap flag). This lets us:
  * Vendor the TH AST for stage1 while keeping template-haskell’s
    dependency surface minimal.
  * Decouple the evolving in-tree TH representation from the shipped
    ghc-boot-th library used in stage2.
  * Avoid allow-newer hacks previously targeting ghc-boot-th.

Key changes:
  * Makefile: add synth-ghc-boot-th-next target; _build/booted depends on
    its .synth-stamp; clean/distclean purge generated artifacts.
  * configure.ac: register new cabal file for substitution.
  * cabal.project.stage1: switch ghc-boot-th → ghc-boot-th-next, add
    bootstrap flags for ghc / ghci / ghc-boot; drop obsolete allow-newer
    override; prune time from stage1 set (stage1 doesn’t need it here).
  * ghc-boot-th.cabal.in: correct hs-source-dirs under bootstrap to use
    ../ghc-boot-th (instead of @sourceroot@), matching the synthesized
    variant layout.
  * compiler/Setup.hs: tolerate missing ghc-internal (fallback
    "<unavailable>") and comment on cStage hack.
  * GHC.Iface.Load: fix getGhcPrimIface usage to pass hsc_hooks
    (API / rebase alignment). (Would have been a fixup if not already
    included in this rebased commit.)

Rationale:
The “next” indirection is a temporary staging device: once the
bootstrap path stabilizes (and/or ghc-internal layering is settled)
we can retire ghc-boot-th-next and fold the logic back, removing the
Makefile synthesis hack.

Future cleanup / follow-ups:
  * Eliminate synthesis step by sharing a parametrised .cabal.in or
    by folding back when layering is finalized.
  * Revisit removal of time if any downstream stage1 tool regresses.
  * Replace cStage hard-code once multi-stage config flow is unified.

Test Plan:
  * make (or make stage1) builds stage1 compiler using ghc-boot-th-next.
  * Verify template-haskell <= 2.22 constraint still satisfied.
  * Build proceeds without manual allow-newer overrides.
  * Ensure synthesized directory contents remain untracked (.gitignore).

Ref: Note [Bootstrapping Template Haskell]

Signed-off-by: Stable Haskell Team <[email protected]>
This incporates the changes from:

git diff ff1f2c0...cf217cd
Comment on lines -75 to +76
-- Darwin-specific tools
, tgtOtool :: Maybe Program
-- Mac specific
, tgtOtool:: Maybe Program
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can bin this change. Seems like it adds nothing useful here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should really try to get this upstreamed. I hope this is fairly uncontroversial.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we shouldn't commit these if they have .in files.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope getting these changes upstreamed is also fairly uncontroversial.

@@ -841,6 +841,7 @@ getWanted verbose os tmpdir gccProgram gccFlags nmProgram mobjdumpProgram
= case words line of
('_' : n) : "C" : s : _ -> mkP n s
n : "C" : s : _ -> mkP n s
n : "B" : _ : s : _ -> mkP n s
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 What was this about?

Comment on lines +34 to +35
default-extensions:
UnboxedSums
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need this?

rts/rts.cabal Outdated
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping this file in sync is going to be super painful. Maybe we should note down in the file itself what upstream commit it was based on, so that it's easier to update it as upstream evolves?

@@ -56,7 +56,7 @@ Library
cpp-options: -DBOOTSTRAP_TH
build-depends:
ghc-prim
hs-source-dirs: @SourceRoot@ ../ghc-internal/src
hs-source-dirs: ../ghc-boot-th ../ghc-internal/src
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really stupid. For ghc-boot-th this works, because well ../ghc-boot-th is the same. For the synthezied -next package, this works, because we look at the ../ghc-boot-th for the modules.

This TH story is such a PITA.

ghc/Main.hs Outdated
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should try to get these changes upstreamed asap.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤯 this just feels like layering hacks upon hacks 😞

@angerman angerman mentioned this pull request Aug 31, 2025
@angerman angerman mentioned this pull request Aug 31, 2025
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.

3 participants