[gentoo-catalyst] [rfc] Compile flag derivation logic (catalyst 2.x)

[gentoo-catalyst] [rfc] Compile flag derivation logic (catalyst 2.x)

[Sebastian Pipping]

Hello!


It seems that in order to get your own compile flags applied for a
stage3 or stage4 build you need to append a "CFLAGS=" line to
/etc/make.conf from within the envscript - quite a dirty workaround not
to mention the fact that the envscript is sourced multiple times.

This is how final CFLAGS seem to be derived (numbers indicate order so
higher numbers win):

  Targets "stage1, "stage2"
    1) key "CFLAGS" subarch defaults
    2) key "CFLAGS" earlier /etc/make.conf
    3) key "cflags" conf file
    4) key "cflags" spec file

  Targets "stage3", "stage4", "generic_stage"
    1) key "CFLAGS" subarch defaults
    2) key "CFLAGS" earlier /etc/make.conf

That explains why my stage4 "subarch: core2" isn't really changing
anything: it gets overriden by the /etc/make.conf from the stage3 I am
using.

Is that what you are expecting?

Is my picture broken - are you experiencing something else with your
stage builds?

Can you thing of reasons to not allow overriding CFLAGS and friends for
stage3 and stage4 builds?

Best,



Sebastian

Re: [gentoo-catalyst] [rfc] Compile flag derivation logic (catalyst 2.x)

[Matt Turner]

On Sat, Jun 25, 2011 at 10:04 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> Hello!
>
>
> It seems that in order to get your own compile flags applied for a
> stage3 or stage4 build you need to append a "CFLAGS=" line to
> /etc/make.conf from within the envscript - quite a dirty workaround not
> to mention the fact that the envscript is sourced multiple times.
>
> This is how final CFLAGS seem to be derived (numbers indicate order so
> higher numbers win):
>
>  Targets "stage1, "stage2"
>    1) key "CFLAGS" subarch defaults
>    2) key "CFLAGS" earlier /etc/make.conf
>    3) key "cflags" conf file
>    4) key "cflags" spec file
>
>  Targets "stage3", "stage4", "generic_stage"
>    1) key "CFLAGS" subarch defaults
>    2) key "CFLAGS" earlier /etc/make.conf
>
> That explains why my stage4 "subarch: core2" isn't really changing
> anything: it gets overriden by the /etc/make.conf from the stage3 I am
> using.
>
> Is that what you are expecting?
>
> Is my picture broken - are you experiencing something else with your
> stage builds?
>
> Can you thing of reasons to not allow overriding CFLAGS and friends for
> stage3 and stage4 builds?

Thanks for writing this up. This has always been a maze to me, so this
is very useful.

I can't think of a situation where CFLAGS specified in the spec or
conf file should be overridden by the CFLAGS in /etc/make.conf. So,
this seems wrong.

Are you saying that cflags specified in the spec file are totally
ignored for stage3 and stage4? That seems totally broken.

Matt

Re: [gentoo-catalyst] [rfc] Compile flag derivation logic (catalyst 2.x)

[Sebastian Pipping]

On 06/26/2011 04:33 AM, Matt Turner wrote:
>>  Targets "stage1, "stage2"
>>    1) key "CFLAGS" subarch defaults
>>    2) key "CFLAGS" earlier /etc/make.conf
>>    3) key "cflags" conf file
>>    4) key "cflags" spec file

I think I need to correct this one to:

    Targets "stage1, "stage2"
     1) key "CFLAGS" subarch defaults
     2) key "cflags" conf file
     3) key "cflags" spec file

So no affect from /etc/make.conf in that case.  The file is read but the
code applying its settings is override in classes stage1_target and
stage2_target (without calling the original code).


>>  Targets "stage3", "stage4", "generic_stage"
>>    1) key "CFLAGS" subarch defaults
>>    2) key "CFLAGS" earlier /etc/make.conf
>>
>> [..]
> 
> [..]
> 
> Are you saying that cflags specified in the spec file are totally
> ignored for stage3 and stage4? That seems totally broken.

That's my impression, yes.

Best,



Sebastian

Re: [gentoo-catalyst] [rfc] Compile flag derivation logic (catalyst 2.x)

[Peter Stuge]

Sebastian Pipping wrote:
> >>  Targets "stage3", "stage4", "generic_stage"
> >>    1) key "CFLAGS" subarch defaults
> >>    2) key "CFLAGS" earlier /etc/make.conf
> > 
> > Are you saying that cflags specified in the spec file are totally
> > ignored for stage3 and stage4? That seems totally broken.
> 
> That's my impression, yes.

Remember that the "proper" way to use catalyst is to build not only
the stage that you want but also those preceding it. So if you want a
stage4 then you should also build 1-2-3 first.

Considering that, it's not actually that bad an idea to only have
CFLAGS set while building stage 2, and later re-use that setting.

That said, this is kinda limited. I'm lazy so when I build my stage4
I start from a ready-made stage3 like I would on a manual install,
and sometimes I run into trouble because of it (perl 5.8->5.12 and
needing to hack perl-cleaner into the stage4 script), and I was
indeed expecting that my spec cflags would apply at least for what
got built in my stage4.


//Peter