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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
