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

[Sam Thursfield <sam thursfield codethink co uk>]

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 ?

Firstly I still don't want to think about this without considering 
testing -- it's a bad idea for a project like Baserock to claim to 
support for a particular board unless we actually have one of those 
boards hooked up to the continuous test infrastructure.

But, supposing we do end up with dozens of different ARM boards, I 
wouldn't want to have a different symbolic arch name for each one, I 
agree. And there's similar need in Linux builds -- enabling different 
hardware options on top of a basic kernel config for different hardware 
families.

I would start by just having a big per-board conditional statement 
though, and when the same things were being duplicated amongst multiple 
boards, factor that out into some other variable. I find it easier to 
thing about this in terms of kernel config.

variables:
  kernel-device-config:
    (?):
      - condition: board == 'pandaboard'
        value: |
          CONFIG_PANDABOARD
          CONFIG_FOO
          CONFIG_BAR
      - condition: board == 'wandboard'
        value: |
         CONFIG_WANDBOARD
         CONFIG_FOO
         CONFIG_BAR
      - condition: board == 'jetson'
        value: |
         CONFIG_JETSON
         CONFIG_FOO
         CONFIG_BAR
         CONFIG_BAZ

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

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.

Sam

--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575