Stage1Only

[Simon Marlow]

Hi Trevor,

That all sounds good to me.  By all means go ahead and submit patches, 
I'll be happy to review them.

Cheers,
	Simon

On 24/06/13 19:46, Trevor Elliott wrote:
> 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
>