Stage1Only

Trevor Elliott trevor at galois.com
Mon Jun 24 20:46:34 CEST 2013


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2311 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130624/53d8c8d3/attachment-0001.bin>


More information about the ghc-devs mailing list