Hi Simon,Sorry about my late response, I haven't had much time to experiment recently.
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.
I think that Ian has integrated this portion of my original patch. Thanks!
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.
I think that the use case here is cross compilation. In order to support a target where you can't run the output of stage1 on the build machine, say cross compilation for ppc from x86, you need to be able to disable certain parts of the build.
Iavor and I did an experiment where we tried to use the set of NOT_NEEDED flags to disable everything built with stage2, to simulate the expected functionality of Stage1Only. We had some good success though one hiccup we ran into was that the build system kept looping as a result. I'd be happy to look into this, as I like the level of granularity that the NOT_NEEDED flags give, and think that they're the base functionality that something like Stage1Only should be implemented in terms of.
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.
The way that some bits of functionality are enabled/disabled in build.mk seems like the right place to set up some default settings for the NOT_NEEDED flags. For example, Stage1Only=YES could just expand out to a set of default values for the NOT_NEEDED flags that prevents anything building with the stage2 compiler. This would just give a name to existing functionality, and allow us to remove all other uses of Stage1Only from the build system. I think that accomplishes your goal of not adding any hacks to the build system to solve a specific problem, while still keeping the intent of Stage1Only. We could even pick a different name for Stage1Only after this change, as it should only be used in one place.
--trevor
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
