Re: [Buildroot] [PATCH 00/16] Bootlin toolchain updates and x86 updates

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Thomas, All,

On 2022-01-25 10:11 +0100, Thomas Petazzoni spake thusly:
> On Tue, 25 Jan 2022 08:58:17 +0100
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > > Thomas Petazzoni (16):
[--SNIP--]
> > >   arch/Config.in.x86: add "newer" names for several Intel x86 CPU
> > >     variants  
> > I was wondering if we should expand the prompt to include the fact that
> > they are deprecated, or specific to gcc versions before 4.9... But
> > whatever I tried was ugly or confusing, so I just left it as-is.
> Originally, I was hoping to simply remove them, and add
> Config.in.legacy entries for these options, selecting the new ones. But
> alas, before gcc 4.9, the "new" names didn't exist.

Yeah, I was wondering why we would not add them to legacy, then I read
the commit log. ;-)

But in the end, I believe legacy should be doable, albeit a bit ugly.

In legacy (only two entries used as example):

    config BR2_x86_corei7
        bool "corei7 has been renamed to nehalem"
        select BR2_LEGACY

    config BR2_x86_atom
        bool "atom has been renamed to bonnel"
        select BR2_LEGACY

And then in the choice in arch/Config.in.x86:

    choice
        bool "Target Architecture Variant"
        default BR2_x86_nehalem if BR2_x86_corei7  # legacy
        default BR2_x86_bonnel if BR2_x86_atom  # legacy
        default default BR2_x86_i586 if BR2_i386
        depends on BR2_i386 || BR2_x86_64    # [0]

    [...]

    config BR2_x86_nehalem
        bool "nehalem (corei7 for gcc < 4.9)"

    config BR2_x86_bonnel
        bool "bonnel (previously: atom)"

    endchoice

    config BR2_GCC_TARGET_ARCH
        [...]
        default "nehalem" if BR2_x86_nehalem && BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
        default "corei7" if BR2_x86_nehalem  # Legacy fallback
        default "bonnel" if BR2_x86_bonnel && BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
        default "atom" if BR2_x86_bonnel # Legacy fallback
        [...]

This is a bit ugly, but a minor inconvenience. Note how I wrote two
different prompts: it's just for illustration purposes, we'll need to
settle on one or the other (or something else).

[0] this dependency is superfluous, as the whole of arch/Config.in.x86
    is already conditionally included with this same condition from
    arch/Config.in

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot