Skip to content

Conversation

@andreabedini
Copy link
Member

  • fix handling of index-state
  • build(stage1): replace submodules with Hackage packages
  • build(stage2): replace submodules with Hackage packages

@andreabedini andreabedini changed the title wip/andrea/no submodules Remove submodules Oct 29, 2025
@andreabedini andreabedini reopened this Oct 29, 2025
@andreabedini andreabedini requested a review from angerman October 29, 2025 05:10
@andreabedini andreabedini force-pushed the wip/andrea/no-submodules branch 4 times, most recently from b9e4f1e to 9ba8d02 Compare November 4, 2025 06:43
capture dependencies of configure scripts and generared files

improve cleaning
  Remove 25 library and utility submodules from .gitmodules and switch to
  using official Hackage releases instead. This simplifies the build system
  and reduces repository complexity.

  • Remove submodule entries for libraries (binary, bytestring, containers,
  etc.) and utilities (hsc2hs, hpc) that are now available as Hackage
  packages
  • Where necessary, include hackage packages as extra-packages in cabal.project files
  • Simplify Makefile by removing library-specific header copy functions
  and submodule-related build rules
  • Replace boot script with direct autoreconf invocations in Makefile
  for configure script generation
  • Update configure target handling to use individual .ac files rather
  than boot script coordination
  • Remove template-hsc.h staging since hsc2hs is now a Hackage package
  • Clean up synthesis logic for ghc-boot-th-next package generation
  • Delete now-obsolete submodule directories and boot orchestration code
@andreabedini andreabedini force-pushed the wip/andrea/no-submodules branch from 9ba8d02 to fe6fcb0 Compare November 28, 2025 04:13
@angerman angerman deleted the branch stable-ghc-9.14-rebased November 29, 2025 02:16
@angerman angerman closed this Nov 29, 2025
@angerman angerman reopened this Nov 29, 2025
@jappeace
Copy link

I think this should be done upstream if possible.

I'd go for a rebase of the entire submodule history on top of ghc directly.
Although this may require a fair bit of git magic.

@angerman
Copy link

I'd go for a rebase of the entire submodule history on top of ghc directly.
Although this may require a fair bit of git magic.

This is not about inlining submodules. This is about using proper facilities to reference them.

  • proper package releases from hackage
  • source-repository-packages in the cabal project.

We can do this in stable-haskell, because we can build ghc just with cabal-install, and don't need hadrian.

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