refactor: remove HADRIAN_SETTINGS environment variable#124
refactor: remove HADRIAN_SETTINGS environment variable#124angerman wants to merge 72 commits intostable-ghc-9.14from
Conversation
This change reverts part of !14544, which forces the bootstrap compiler to have ghc-internal. As such it breaks booting with ghc 9.8.4. A better solution would be to make this conditional on the ghc version in the cabal file!
…ernal If the boot compiler doesn't have ghc-internal use "<unavailble>" as the `cGhcInternalUnitId`. This allows booting with older compilers. The subsequent stage2 compilers will have the proper ghc-internal id from their stage1 compiler, that boots them.
mermaid is a common diagram format that can be inlined in markdown files, and e.g. github will even render it. This change adds support for mermaid diagram output to ghc-pkg.
This adds support to ghc-pkg to infer a package-db from a target name.
Make the first simple optimization pass after desugaring a real CoreToDo pass. This allows CorePlugins to decide whether they want to be executed before or after this pass.
It's more user-friendly to directly print the right thing instead of requiring the user to retry with the additional `-dppr-debug` flag.
…roken on darwin/non-dynamic.
The referenced issue 20706 also doesn't list T13786 as a broken test.
By mistake we tried to use deriveConstant without passing `--gcc-flag -fcommon` (which Hadrian does) and it failed. This patch adds deriveConstant support for constants stored in the .bss section so that deriveConstant works without passing `-fcommon` to the C compiler.
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 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.
While we do want to drop this, for now, to keep the diff to upstream small, we will just disable it with [10,100] range, which should include all relevent LLVM versions in the foresable future.
Since we now ignore loading ANY rts dependency.
Replace legacy __sync_fetch_and_* builtins with their modern __atomic_fetch_*
equivalents. This simplifies the code significantly, particularly for the nand
operation which previously required extensive workarounds for compiler
compatibility issues.
Changes:
- Replace __sync_fetch_and_{add,sub,and,or,xor} with __atomic_fetch_*
- Replace __sync_fetch_and_nand with __atomic_fetch_nand
- Remove CAS-based fallback for nand operations
- Remove compiler-specific warning suppressions for -Wsync-nand
- Remove volatile qualifiers (not needed with __atomic builtins)
- Update comments to reflect modern atomics usage
All operations maintain __ATOMIC_SEQ_CST memory ordering for sequential
consistency, matching the original behavior.
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>
#107) * docs(readme): consolidate building and contributing guides into README - Delete separate HACKING.md and INSTALL.md files, consolidating their content into README.md for a unified reference - Update README to reflect Stable Haskell Edition fork with GitHub issue tracker at stable-haskell/ghc - Revise clone instructions to point to GitHub stable-haskell/ghc repository instead of GitLab - Simplify build instructions to use make-based build system with clearer GHCup setup steps - Integrate developer contribution guidelines and communication channels directly into README - Update dependency references and remove outdated tool links (Happy, Alex) - Add test suite running instructions to building section - Reorganize content with clearer section headers for Getting Started, Useful Resources, and communication channels
capture dependencies of configure scripts and generared files improve cleaning
- Improve the consistency across the stage cabal.project files by using the same ordering and delimiter comments - "package-dbs: clear, global" is the default so it's removed
The refactoring in 'reorganize cabal.project files' accidentally removed libraries/ghc-platform from cabal.project.stage1. This package is required because ghc-boot depends on ghc-platform >= 0.1. Without this fix, all CI builds fail with: Error: [Cabal-7107] Could not resolve dependencies: unknown package: host:ghc-platform (dependency of host:ghc-boot)
Add entries to prevent AI agent config files from being accidentally committed. These files contain project-specific instructions for various AI coding assistants and should remain local. Covers: Claude Code, GitHub Copilot, Cursor, Gemini CLI/Jules, OpenAI Codex, and JetBrains Junie. See: https://agents.md/ for the AGENTS.md standard
Version and platform info is now generated directly by ./configure into: - libraries/ghc-boot/GHC/Version.hs (from Version.hs.in) - libraries/ghc-boot/GHC/Platform/Host.hs (from Host.hs.in) This eliminates the fragile HADRIAN_SETTINGS environment variable mechanism that passed version/platform info from Makefile to cabal's custom Setup.hs. Changes: - Add platform detection to configure.ac using uname with auto-detect - Add --with-target-arch and --with-target-os configure arguments - Add --with-project-git-commit-id configure argument (auto-detects) - Create Version.hs.in and Host.hs.in templates - Simplify Setup.hs to use defaultMain (no more custom hooks) - Change ghc-boot.cabal.in build-type from Custom to Simple - Remove autogen-modules from ghc-boot.cabal.in - Remove all HADRIAN_SETTINGS references from Makefile
hsyl20
left a comment
There was a problem hiding this comment.
If top-level configure does the substitution, how does it work when we build a cross-compiler (i.e. stage1 is non-cross and stage2 is cross)? The specified target should only apply to the stage2 compiler (stage1 is always non-cross).
Yea, I think we need to get rid of the target logic outright. This was just a first stab at nuking the Ultimately stage1 is always a native and stage2 is always a multi-target compiler (native + cross) compiler. In that case a single "target" is really not that meaningful. I think the solution is to just kill the target conditionals in a second step. For now this is just trying to do the same, just without |
9cbe6d3 to
a206e83
Compare
Summary
HADRIAN_SETTINGSenvironment variable mechanism./configureinto template filesChanges
configure.acuname), added--with-target-arch,--with-target-os,--with-project-git-commit-idargumentslibraries/ghc-boot/GHC/Version.hs.inlibraries/ghc-boot/GHC/Platform/Host.hs.inMakefileHADRIAN_SETTINGSdefinition and all usages, updatedCONFIGURED_FILESlistlibraries/ghc-boot/Setup.hsdefaultMain(130 → 11 lines)libraries/ghc-boot/ghc-boot.cabal.inbuild-type: Custom→Simple, removedcustom-setupandautogen-modulesHow It Works Now
Configure auto-detects platform using
uname -manduname -s, with override options:Configure generates the modules directly from templates:
libraries/ghc-boot/GHC/Version.hs- version strings, git commitlibraries/ghc-boot/GHC/Platform/Host.hs- platform arch/OS typesNo more environment variable passing between Makefile and Cabal
Benefits
configure.ac) for version/platform infoghcversion.h.in)Test plan
./configureand verify generated files have correct contentmake CABAL=$PWD/_build/stage0/bin/cabal stage1_build/stage1/bin/ghc --versionshows correct version