marlowsd at gmail.com
Fri Jun 28 11:11:02 CEST 2013
That all sounds good to me. By all means go ahead and submit patches,
I'll be happy to review them.
On 24/06/13 19:46, Trevor Elliott wrote:
> Hi Simon,
> Sorry about my late response, I haven't had much time to experiment
>>> Making with stage=1 causes the rts to never build. Additionally, GHC
>>> failing to build on the master branch with stage=1 when I submitted the
>> 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
>>> 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
>>> 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.
More information about the ghc-devs