On 30 April 2013 19:03, Trevor Elliott <tre...@galois.com> wrote: >> I'm a bit confused - what is the issue that you want to "fix"? The fix >> I suggested was to change the name of Stage1Only to more closely reflect >> what it actually does: disable the building of the stage 2 compiler >> *binary* but not the *package*, and install the stage 1 compiler. If >> you additionally want to disable the stage 2 package, you can add >> stage=1 to your build.mk, though the only reason to do that would be to >> speed up the build in cases where you don't need stage 2. > > > Making with stage=1 causes the rts to never build. Additionally, GHC was > failing to build on the master branch with stage=1 when I submitted the > patch.
So these are just bugs that we should fix. There's no good reason that stage=1 should prevent the RTS from building. > My goal was to make it so that generating a cross compiler /only/ was > feasible with the build system, as well as allow packages and tools to be > disabled for targets where they don't make sense, like the HaLVM. The way > things are currently, you'll generate much of the target toolchain in > addition to the stage 1 cross compiler. Stage1Only seemed like the > documented way to go about this on the wiki, but it seems like nobody feels > this should be a supported feature. If there's a valid use case and people want it, it should definitely be a supported feature. My main concern is to try not to add hacks to the build system to solve very specific problems, but instead think about more general concepts. For example, we're accumulating ways to disable certain subsets of the build - Stage1Only=YES, stage=1, and whatever you need, so probably they should be collected together and should look similar. Cheers, Simon > I'd really like to see something in the spirit of Stage1Only, and > package/tool disabling working, as it would allow us to more closely > integrate the HaLVM with the ghc build system. I'm very much willing to do > the work if you and Ian can give me some pointers for how you'd like it > done. > > --trevor > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs