
I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say

(apols for premature send) I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say hadrian/build and I get the log below. It falls over saying No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs. Surely that should not happen? I'll try make clean; but isn't this a bug? Simon

Hi Simon, You have to re-run `./configure` in cases like this. It's because `compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by `./configure`. This isn't tracked by Hadrian.
Surely that should not happen?I'll try make clean; but isn't this a bug?
Hopefully when `make` build system will be removed it should be easy to make Hadrian (instead of `./configure`) generate and track this file. In fact I already did this in a MR more than a year ago but it was blocked on make-removal. Sylvain On 11/07/2022 17:09, Simon Peyton Jones wrote:
(apols for premature send)
I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say hadrian/build and I get the log below. It falls over saying No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
Surely that should not happen?
I'll try make clean; but isn't this a bug?
Simon
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

It is advisable to do this after rebasing, especially if the rebase involves changes to the module structure or build system.
But *any* commit could involve such a change. Isn't it a goal of Hadrian
to respond to, well, changes? For example, it is clever enough to rebuild
Hadrian itself when it changes.
It's a bit unsatisfying to say "it'll usually work, but if anything strange
happens, just make clean and try again". Understandable perhaps, but not
satisfying.
Simon
On Mon, 11 Jul 2022 at 16:19, Sylvain Henry
Hi Simon,
You have to re-run `./configure` in cases like this. It's because `compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by `./configure`. This isn't tracked by Hadrian.
Surely that should not happen? I'll try make clean; but isn't this a bug?
Hopefully when `make` build system will be removed it should be easy to make Hadrian (instead of `./configure`) generate and track this file. In fact I already did this in a MR more than a year ago but it was blocked on make-removal.
Sylvain
On 11/07/2022 17:09, Simon Peyton Jones wrote:
(apols for premature send)
I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say hadrian/build and I get the log below. It falls over saying No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
Surely that should not happen?
I'll try make clean; but isn't this a bug?
Simon
_______________________________________________ ghc-devs mailing listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Yes, but as Sylvain noted, the configure step (which generates ghc.cabal and so is particularly sensitive to changes in module structure) is not tracked by hadrian at the moment. We could in principle fix this, and as also noted by Sylvain this will become much easier once Make no longer exists. On 22/07/11 16:25, Simon Peyton Jones wrote:
It is advisable to do this after rebasing, especially if the rebase involves changes to the module structure or build system.
But *any* commit could involve such a change. Isn't it a goal of Hadrian to respond to, well, changes? For example, it is clever enough to rebuild Hadrian itself when it changes.
It's a bit unsatisfying to say "it'll usually work, but if anything strange happens, just make clean and try again". Understandable perhaps, but not satisfying.
Simon
On Mon, 11 Jul 2022 at 16:19, Sylvain Henry
wrote: Hi Simon,
You have to re-run `./configure` in cases like this. It's because `compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by `./configure`. This isn't tracked by Hadrian.
Surely that should not happen? I'll try make clean; but isn't this a bug?
Hopefully when `make` build system will be removed it should be easy to make Hadrian (instead of `./configure`) generate and track this file. In fact I already did this in a MR more than a year ago but it was blocked on make-removal.
Sylvain
On 11/07/2022 17:09, Simon Peyton Jones wrote:
(apols for premature send)
I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say hadrian/build and I get the log below. It falls over saying No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
Surely that should not happen?
I'll try make clean; but isn't this a bug?
Simon
_______________________________________________ ghc-devs mailing listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

OK. So it's a bug. Do we have an open Hadrian ticket to track it? If
not, might you open one?
Make *already *no longer exists, incidentally. Nowadays we need ghc-9.2
to build HEAD, and make doesn't work with ghc-9.2 for some reason. So I
believe that make is dead for HEAD at least.
Simon
On Mon, 11 Jul 2022 at 16:36, Zubin Duggal
Yes, but as Sylvain noted, the configure step (which generates ghc.cabal and so is particularly sensitive to changes in module structure) is not tracked by hadrian at the moment. We could in principle fix this, and as also noted by Sylvain this will become much easier once Make no longer exists.
On 22/07/11 16:25, Simon Peyton Jones wrote:
It is advisable to do this after rebasing, especially if the rebase involves changes to the module structure or build system.
But *any* commit could involve such a change. Isn't it a goal of Hadrian to respond to, well, changes? For example, it is clever enough to rebuild Hadrian itself when it changes.
It's a bit unsatisfying to say "it'll usually work, but if anything strange happens, just make clean and try again". Understandable perhaps, but not satisfying.
Simon
On Mon, 11 Jul 2022 at 16:19, Sylvain Henry
wrote: Hi Simon,
You have to re-run `./configure` in cases like this. It's because `compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by `./configure`. This isn't tracked by Hadrian.
Surely that should not happen? I'll try make clean; but isn't this a bug?
Hopefully when `make` build system will be removed it should be easy to make Hadrian (instead of `./configure`) generate and track this file. In fact I already did this in a MR more than a year ago but it was blocked on make-removal.
Sylvain
On 11/07/2022 17:09, Simon Peyton Jones wrote:
(apols for premature send)
I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say hadrian/build and I get the log below. It falls over saying No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
Surely that should not happen?
I'll try make clean; but isn't this a bug?
Simon
_______________________________________________ ghc-devs mailing listghc-devs@haskell.orghttp:// mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

It seems like GHC.Unit.Module.Name was recently removed/renamed in commit c43dbac08b0d56406fe13de1e9b49c944f478b4a (Refactor ModuleName to L.H.S.Module.Name). What is probably going on is that as that file no longer exists in the compiler/ source directory, but presumably some references to it still exist in your hadrian _build directory, hadrian believes it a generated file (like GHC.Settings.Config or All you need to fix this is to delete the _build directory, which is the hadrian build root you are using. It is advisable to do this after rebasing, especially if the rebase involves changes to the module structure or build system. On 22/07/11 16:09, Simon Peyton Jones wrote:
(apols for premature send)
I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say hadrian/build and I get the log below. It falls over saying No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
Surely that should not happen?
I'll try make clean; but isn't this a bug?
Simon
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

And like Sylvain says, you also do need to reconfigure. On 22/07/11 20:51, Zubin Duggal wrote:
It seems like GHC.Unit.Module.Name was recently removed/renamed in commit c43dbac08b0d56406fe13de1e9b49c944f478b4a (Refactor ModuleName to L.H.S.Module.Name).
What is probably going on is that as that file no longer exists in the compiler/ source directory, but presumably some references to it still exist in your hadrian _build directory, hadrian believes it a generated file (like GHC.Settings.Config or
All you need to fix this is to delete the _build directory, which is the hadrian build root you are using. It is advisable to do this after rebasing, especially if the rebase involves changes to the module structure or build system.
On 22/07/11 16:09, Simon Peyton Jones wrote:
(apols for premature send)
I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say hadrian/build and I get the log below. It falls over saying No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
Surely that should not happen?
I'll try make clean; but isn't this a bug?
Simon
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (3)
-
Simon Peyton Jones
-
Sylvain Henry
-
Zubin Duggal