So this did something different, but still tries to build tools like hsc2hs with the stage1 compiler. This won't really work for a target like the HaLVM, as there's no notion of a filesystem in the target environment. So, back to my original question: what's the easiest way to just generate a stage1 compiler and the libraries that it will require? Thanks! --trevor On 04/08/2013 06:07 PM, Trevor Elliott wrote:

I searched on trac for bugs relating to Stage1Only, and didn't come up with anything, but a google search turned up this:

http://hackage.haskell.org/trac/ghc/ticket/7639

I'm going to try passing stage=1 in build.mk.

--trevor

On 04/08/2013 05:20 PM, Trevor Elliott wrote:

...

Hi Everyone,

I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools.

What is the best way to stop the build system after stage1 + libraries has finished?

Thanks!

--trevor

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On 4/9/13, Gabor Greif wrote:

On 4/9/13, Trevor Elliott wrote:

...

So this did something different, but still tries to build tools like hsc2hs with the stage1 compiler. This won't really work for a target like the HaLVM, as there's no notion of a filesystem in the target environment.

I made the same observation. In cross-mode with Stage1Only many (if not all) of the compiler/ lib is built, but there is no final linking of stage2.

Following up on this... The relevant excerpt from the make --debug log seems to be Successfully remade target file `all_compiler_stage1'. File `all_compiler' does not exist. File `all_compiler_stage2' does not exist. File `all_compiler_stage2_v' does not exist. File `compiler/stage2/build/libHSghc-7.7.20130407.a' does not exist. Apparently all_compiler depends on all_compiler_stage2 currently, which it should not, given $(Stage1Only)=="YES". Let's see if I can fix it. Cheers, Gabor

Gabor

...

So, back to my original question: what's the easiest way to just generate a stage1 compiler and the libraries that it will require?

Thanks!

--trevor

On 04/08/2013 06:07 PM, Trevor Elliott wrote:

...

I searched on trac for bugs relating to Stage1Only, and didn't come up with anything, but a google search turned up this:

http://hackage.haskell.org/trac/ghc/ticket/7639

I'm going to try passing stage=1 in build.mk.

--trevor

On 04/08/2013 05:20 PM, Trevor Elliott wrote:

...

Hi Everyone,

I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools.

What is the best way to stop the build system after stage1 + libraries has finished?

Thanks!

--trevor

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi Ian, I've seen this ticket (see [1]), and stage=1 only worked if I explicitly disabled building packages like ghc, and the tools with the stage 1 compiler. This seemed reasonable, as I only wanted to build a cross compiler, not a toolchain for my target. Additionally, I found that the RTS would never get built as a dependency for ghc-prim when using stage=1. The ghc-prim package only builds dist-boot and dist-install variants, and the RTS only ever builds a dist variant. When dependencies are generated in build-package-way for ghc-prim, the variable rts-1.0_dist-install_$(way)_LIB expands to "", and ghc-prim builds without forcing the RTS to also build. I've fixed this by adding a dist-install alias (listed below) in rts/ghc.mk, as well as adding $$($1_$2_$3_DEPS_LIBS) to the dependencies of the static archive rule in rules/build-package-way.mk.

rts-$(rts_VERSION)_dist-install_$1_LIB = $$(rts_$1_LIB)

I have some other changes that make Stage1Only work as expected, and would be happy to submit a patch if it's desired functionality. Thanks! --trevor [1] http://www.haskell.org/pipermail/ghc-devs/2013-April/001002.html On Fri 12 Apr 2013 05:58:40 AM PDT, Ian Lynagh wrote:

On Fri, Apr 12, 2013 at 02:51:44PM +0200, Gabor Greif wrote:

...

Apparently all_compiler depends on all_compiler_stage2 currently, which it should not, given $(Stage1Only)=="YES".

See http://hackage.haskell.org/trac/ghc/ticket/7639#comment:5

Thanks Ian

On 12/04/13 05:51, Gabor Greif wrote:

On 4/9/13, Gabor Greif wrote:

...

On 4/9/13, Trevor Elliott wrote:

...

So this did something different, but still tries to build tools like hsc2hs with the stage1 compiler. This won't really work for a target like the HaLVM, as there's no notion of a filesystem in the target environment.

I made the same observation. In cross-mode with Stage1Only many (if not all) of the compiler/ lib is built, but there is no final linking of stage2.

Following up on this...

The relevant excerpt from the make --debug log seems to be

Successfully remade target file `all_compiler_stage1'. File `all_compiler' does not exist. File `all_compiler_stage2' does not exist. File `all_compiler_stage2_v' does not exist. File `compiler/stage2/build/libHSghc-7.7.20130407.a' does not exist.

Apparently all_compiler depends on all_compiler_stage2 currently, which it should not, given $(Stage1Only)=="YES".

Let's see if I can fix it.

http://www.quickmeme.com/meme/3twwox/ Setting Stage1Only=YES says "build the stage 1 compiler and all of the packages". Guess what? Stage 2 is one of the packages. :-) In retrospect I should have used a different name. Feel free to fix it (and the wiki page). Cheers, Simon

Cheers,

Gabor

...

Gabor

...

So, back to my original question: what's the easiest way to just generate a stage1 compiler and the libraries that it will require?

Thanks!

--trevor

On 04/08/2013 06:07 PM, Trevor Elliott wrote:

...

I searched on trac for bugs relating to Stage1Only, and didn't come up with anything, but a google search turned up this:

http://hackage.haskell.org/trac/ghc/ticket/7639

I'm going to try passing stage=1 in build.mk.

--trevor

On 04/08/2013 05:20 PM, Trevor Elliott wrote:

...

Hi Everyone,

I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools.

What is the best way to stop the build system after stage1 + libraries has finished?

Thanks!

--trevor

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On 15/04/13 22:25, Trevor Elliott wrote:

...

In retrospect I should have used a different name. Feel free to fix it (and the wiki page).

I've created a ticket with a patch that I think addresses this issue [1]. The patch adds a mechanism that allows packages and programs to be disabled when building with a specific stage of GHC. It also adds a default set of disabled packages when Stage1Only is set.

I'm a bit confused - what is the issue that you want to "fix"? The fix I suggested was to change the name of Stage1Only to more closely reflect what it actually does: disable the building of the stage 2 compiler *binary* but not the *package*, and install the stage 1 compiler. If you additionally want to disable the stage 2 package, you can add stage=1 to your build.mk, though the only reason to do that would be to speed up the build in cases where you don't need stage 2. What is it that actually goes wrong for you? Cheers, Simon

A side effect of this change is that no package adds an RTS dependency when Stage1Only is enabled, so I've also added all_rts to the all target in rts/ghc.mk. I wasn't able to figure out where the dependency on the all_rts target comes from, so if that change doesn't make sense I'm happy to modify the attached patch :)

--trevor

[1] http://hackage.haskell.org/trac/ghc/ticket/7841

On 30 April 2013 19:03, Trevor Elliott wrote:

...

I'm a bit confused - what is the issue that you want to "fix"? The fix I suggested was to change the name of Stage1Only to more closely reflect what it actually does: disable the building of the stage 2 compiler *binary* but not the *package*, and install the stage 1 compiler. If you additionally want to disable the stage 2 package, you can add stage=1 to your build.mk, though the only reason to do that would be to speed up the build in cases where you don't need stage 2.

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.

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. 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. Cheers, Simon

I'd really like to see something in the spirit of Stage1Only, and package/tool disabling working, as it would allow us to more closely integrate the HaLVM with the ghc build system. I'm very much willing to do the work if you and Ian can give me some pointers for how you'd like it done.

--trevor

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