Stage1Only

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Stage1Only

Trevor Elliott-3
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

-------------- 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/20130408/85cae739/attachment.bin>

Reply | Threaded
Open this post in threaded view
|

Stage1Only

Trevor Elliott-3
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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-------------- 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/20130408/28190c2e/attachment.bin>

Reply | Threaded
Open this post in threaded view
|

Stage1Only

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

-------------- 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/20130408/637e9c5c/attachment.bin>

Reply | Threaded
Open this post in threaded view
|

Stage1Only

Gabor Greif-2
On 4/9/13, Trevor Elliott <trevor at galois.com> 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.

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


Reply | Threaded
Open this post in threaded view
|

Stage1Only

Gabor Greif-2
On 4/9/13, Gabor Greif <ggreif at gmail.com> wrote:
> On 4/9/13, Trevor Elliott <trevor at galois.com> 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 at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Stage1Only

Ian Lynagh-2
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



Reply | Threaded
Open this post in threaded view
|

Stage1Only

Trevor Elliott-3
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
>

-------------- 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/20130412/6157a29a/attachment-0001.bin>

Reply | Threaded
Open this post in threaded view
|

Stage1Only

Gabor Greif-2
On 4/12/13, Trevor Elliott <trevor at galois.com> wrote:
> 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.

My preliminary experience is that cabal fails (somewhere) because it
cannot locate the 'ghc' package. So I've built without "stage=1"
first, and after cabal did its thing (and the 'relocation out of
range' error stopped my build) I re-issued a make with "stage=1".

This brought me till the already known dyn problem with integer-simple.

Cheers,

    Gabor

>
> 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
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Stage1Only

Simon Marlow-7
In reply to this post by Gabor Greif-2
On 12/04/13 05:51, Gabor Greif wrote:

> On 4/9/13, Gabor Greif <ggreif at gmail.com> wrote:
>> On 4/9/13, Trevor Elliott <trevor at galois.com> 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 at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>
>>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



Reply | Threaded
Open this post in threaded view
|

Stage1Only

Trevor Elliott-3
> 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.

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

-------------- 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/20130415/19672d15/attachment.bin>

Reply | Threaded
Open this post in threaded view
|

Stage1Only

Simon Marlow-7
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
>



Reply | Threaded
Open this post in threaded view
|

Stage1Only

Trevor Elliott-3
> 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.

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.

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

-------------- 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/20130430/0692e033/attachment.bin>

Reply | Threaded
Open this post in threaded view
|

Stage1Only

Simon Marlow-7
On 30 April 2013 19:03, Trevor Elliott <trevor at galois.com> 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
>


Reply | Threaded
Open this post in threaded view
|

Stage1Only

Trevor Elliott-3
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>

Reply | Threaded
Open this post in threaded view
|

Stage1Only

Simon Marlow-7
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
>