Re: Low level compiler tuning (was: Re: Project options and other format enhancements (and dropping "variants"))





On Tue, Sep 19, 2017 at 5:22 PM Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:
On Tue, 2017-09-19 at 16:03 +0100, Sam Thursfield wrote:
> On 19/09/17 02:05, Tristan Van Berkom wrote:
> > Lets phrase it a different way:
> >
> >    If I wanted to salvage what I consider to be one of the most
> >    interesting bits of yocto (the referred machine database above
> >    and all of those rich compiler tunings);
> >
> >    Would I be able to translate that database into some a single
> >    arch features list; and also have gcc bootstrapping build
> >    instructions which consume that list seamlessly ?
> >
> >    What will I be missing ? Will I get an error (before running
> >    the actual build), when I specify an arm specific board feature
> >    but I'm trying to build a mips targeting compiler ?
> >
> >    How do I, as a user, know exactly which flags to specify for
> >    this exact CPU architecture ? Can't I browse a list of
> > implemented
> >    architectures and hope that mine is there ?
[...]

> (As an aside, i've kind of invented a "switch statement" here by writing 
> a list of conditions; I don't know I would write this using just the 
> primitive from your original proposal)

Actually what you write here is valid according to my original
proposal, it's not truly a switch/case thing but rather a collection of
ifs (you have to redundantly specify the 'board' variable, and you
cannot insert breaks to avoid casing the following ifs).

There was an example for this at "Condition list at the toplevel", and
it was listed as one of the considerations; basically that:

   if we have multiple orthogonal settings which can each cause yaml
   composition to happen; the user needs to be able to control the
   order in which they are resolved.


> This could be then factored out to:
>
>
> variables:
>    kernel-config-foobar: |
>            CONFIG_FOO
>            CONFIG_BAR
>    kernel-device-config:
>      (?):
>        - condition: board == 'pandaboard'
>          value: |
>            CONFIG_PANDABOARD
>            %{kernel-config-foobar}
>        - condition: board == 'wandboard'
>          value: |
>           CONFIG_WANDBOARD
>            %{kernel-config-foobar}
>        - condition: board == 'jetson'
>          value: |
>           CONFIG_JETSON
>            %{kernel-config-foobar}
>           CONFIG_BAZ
>
>
> I assume we could take a similar approach for GCC tuning flags.

Wow thanks for thinking about this Sam !

This looks like quite a workable approach, I just wasnt seeing it this
way.

The conditional variables look like an interesting approach.

Random thought, might we actually want to limit conditionals to variables for now?  If we end up wanting to change conditionals it would be contained.

Cheers,

Sander
 
Cheers,
    -Tristan

_______________________________________________
Buildstream-list mailing list
Buildstream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]