[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Yann E. MORIN]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

Currently, all target options lie in the top-level menu.
This looks a bit clumsy, since all other options are neatly
folded into their own sematic sub-menus each.

Move the target option into their own sub-menu too.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 arch/Config.in | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/Config.in b/arch/Config.in
index 0b5b218..640926a 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -1,3 +1,5 @@
+menu "Target options"
+
 config BR2_ARCH_IS_64
 	bool
 
@@ -324,3 +326,5 @@ endif
 if BR2_xtensa
 source "arch/Config.in.xtensa"
 endif
+
+endmenu # Target options
-- 
1.8.1.2

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Arnout Vandecappelle]

On 15/08/13 22:28, Yann E. MORIN wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
> Currently, all target options lie in the top-level menu.
> This looks a bit clumsy, since all other options are neatly
> folded into their own sematic sub-menus each.
>
> Move the target option into their own sub-menu too.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
>   arch/Config.in | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/arch/Config.in b/arch/Config.in
> index 0b5b218..640926a 100644
> --- a/arch/Config.in
> +++ b/arch/Config.in
> @@ -1,3 +1,5 @@
> +menu "Target options"

  I completely agree with the idea - especially in the xconfig, the big 
list of architecture options is extremely annoying. However, the menu 
title is not very clear. How about "Target architecture selection"? Or maybe

Target CPU architecture

   Target CPU architecture family

   Target CPU architecture variant


  Regards,
  Arnout

> +
>   config BR2_ARCH_IS_64
>   	bool
>
> @@ -324,3 +326,5 @@ endif
>   if BR2_xtensa
>   source "arch/Config.in.xtensa"
>   endif
> +
> +endmenu # Target options
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Thomas De Schampheleire]

On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 15/08/13 22:28, Yann E. MORIN wrote:
>>

>> diff --git a/arch/Config.in b/arch/Config.in
>> index 0b5b218..640926a 100644
>> --- a/arch/Config.in
>> +++ b/arch/Config.in
>> @@ -1,3 +1,5 @@
>> +menu "Target options"
>
>
>  I completely agree with the idea - especially in the xconfig, the big list
> of architecture options is extremely annoying. However, the menu title is
> not very clear. How about "Target architecture selection"? Or maybe
>
> Target CPU architecture
>
>   Target CPU architecture family
>
>   Target CPU architecture variant
>

Well, I think the menu provides more than just the cpu architecture
choice. It includes other things like ABI choice, binary format
selection, and floating point strategy. The name 'target options' fits
better for these options than anything with 'target cpu architecture'
in it, but I'm open for other suggestions.

While we're at reorganizing the top-level menu: I find the order of
the menus odd. Current order is;
(Target options)
Build options
Toolchain
System configuration
Package selection for the target
Host utilities
Filesystem images
Bootloaders
Kernel
Legacy config options

I think Bootloaders and Kernel should come earlier in the list and
reversed, and Host utilities should be after filesystem images.
My proposal is thus:
(Target options)
Build options
Toolchain
System configuration
Package selection for the target
Kernel
Bootloaders
Filesystem images
Host utilities
Legacy config options

What is your opinion?

Thanks,
Thomas

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Yann E. MORIN]

Thomas, Arnout, All,

On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> > On 15/08/13 22:28, Yann E. MORIN wrote:
> >>
> 
> >> diff --git a/arch/Config.in b/arch/Config.in
> >> index 0b5b218..640926a 100644
> >> --- a/arch/Config.in
> >> +++ b/arch/Config.in
> >> @@ -1,3 +1,5 @@
> >> +menu "Target options"
> >
> >
> >  I completely agree with the idea - especially in the xconfig, the big list
> > of architecture options is extremely annoying. However, the menu title is
> > not very clear. How about "Target architecture selection"? Or maybe
> >
> > Target CPU architecture
> >
> >   Target CPU architecture family
> >
> >   Target CPU architecture variant
> >
> 
> Well, I think the menu provides more than just the cpu architecture
> choice. It includes other things like ABI choice, binary format
> selection, and floating point strategy. The name 'target options' fits
> better for these options than anything with 'target cpu architecture'
> in it, but I'm open for other suggestions.

Ditto.

> While we're at reorganizing the top-level menu: I find the order of
> the menus odd.
[--SNIP--]
> I think Bootloaders and Kernel should come earlier in the list and
> reversed, and Host utilities should be after filesystem images.
> My proposal is thus:
> (Target options)
> Build options
> Toolchain
> System configuration
> Package selection for the target
> Kernel
> Bootloaders
> Filesystem images
> Host utilities
> Legacy config options
> 
> What is your opinion?

I would even put the kernel before the packages, and bootloaders before
kernel. Ie. I'd use the boot-time order of things:
    (Target options)
    Build options
    Toolchain
    System configuration
    Bootloaders
    Kernel
    Packages selection
    Filesystem images
    Host Utilities
    Legacy config options

Bizzarely enough, moving bootloaders before kernel seems odd... :-/

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Thomas De Schampheleire]

On Fri, Aug 16, 2013 at 8:39 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, Arnout, All,
>
> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> > On 15/08/13 22:28, Yann E. MORIN wrote:
>> >>
> I would even put the kernel before the packages, and bootloaders before
> kernel. Ie. I'd use the boot-time order of things:
>     (Target options)
>     Build options
>     Toolchain
>     System configuration
>     Bootloaders
>     Kernel
>     Packages selection
>     Filesystem images
>     Host Utilities
>     Legacy config options
>
> Bizzarely enough, moving bootloaders before kernel seems odd... :-/


I can follow this boot-time order strategy, but I concur with the
bootloader odditi.

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Thomas De Schampheleire]

On Fri, Aug 16, 2013 at 12:24 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> On Fri, Aug 16, 2013 at 8:39 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> Thomas, Arnout, All,
>>
>> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
>>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> > On 15/08/13 22:28, Yann E. MORIN wrote:
>>> >>
>> I would even put the kernel before the packages, and bootloaders before
>> kernel. Ie. I'd use the boot-time order of things:
>>     (Target options)
>>     Build options
>>     Toolchain
>>     System configuration
>>     Bootloaders
>>     Kernel
>>     Packages selection
>>     Filesystem images
>>     Host Utilities
>>     Legacy config options
>>
>> Bizzarely enough, moving bootloaders before kernel seems odd... :-/
>
>
> I can follow this boot-time order strategy, but I concur with the
> bootloader oddity.

[sorry, accidentally hit send button]

Here is a slightly different viewpoint: some users will never touch
the bootloader. However, creating a kernel and rootfs (possibly
attached to the kernel) is very common. This can result in the
following order:

(Target options)
Build options
Toolchain
System configuration
Kernel
Package selection for the target
Filesystem images
Bootloaders
Host Utilities
Legacy config options


By the way: isn't it more logical to put 'Bootloaders' in singular
(Bootloader), since one typically builds only one bootloader, just as
one only builds one kernel...

Best regards,
Thomas

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Yann E. MORIN]

Thomas, All,

On 2013-08-16 12:30 +0200, Thomas De Schampheleire spake thusly:
> On Fri, Aug 16, 2013 at 12:24 PM, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
> > On Fri, Aug 16, 2013 at 8:39 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >> Thomas, Arnout, All,
> >>
> >> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
> >>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> >>> > On 15/08/13 22:28, Yann E. MORIN wrote:
> >>> >>
> >> I would even put the kernel before the packages, and bootloaders before
> >> kernel. Ie. I'd use the boot-time order of things:
> >>     (Target options)
> >>     Build options
> >>     Toolchain
> >>     System configuration
> >>     Bootloaders
> >>     Kernel
> >>     Packages selection
> >>     Filesystem images
> >>     Host Utilities
> >>     Legacy config options
> >>
> >> Bizzarely enough, moving bootloaders before kernel seems odd... :-/
> >
> >
> > I can follow this boot-time order strategy, but I concur with the
> > bootloader oddity.
> 
> [sorry, accidentally hit send button]
> 
> Here is a slightly different viewpoint: some users will never touch
> the bootloader. However, creating a kernel and rootfs (possibly
> attached to the kernel) is very common. This can result in the
> following order:
> 
> (Target options)
> Build options
> Toolchain
> System configuration
> Kernel
> Package selection for the target
> Filesystem images
> Bootloaders
> Host Utilities
> Legacy config options

Hey! It looks good to me! :-)
I'll handle this. Thanks!

> By the way: isn't it more logical to put 'Bootloaders' in singular
> (Bootloader), since one typically builds only one bootloader, just as
> one only builds one kernel...

This is two-sided:
  - either you consider what Buildroot has to offer: one kernel, and
    multiple bootloaders;
  - or you consider what the user may want to install on the targe, at
    most one kernel, and at most one bootloader.

I prefer the first option. If at some point in the future Buildroot gets
support for alternative kernels (GNU/Hurd, someone? ;-) ), then we'd
have to s/Kernel/Kernels/.

Consequently, "Package selection for the target" should be a plural
"Packages selection for target".

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Thomas De Schampheleire]

On Fri, Aug 16, 2013 at 7:59 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, All,
>
> On 2013-08-16 12:30 +0200, Thomas De Schampheleire spake thusly:
>>
>> Here is a slightly different viewpoint: some users will never touch
>> the bootloader. However, creating a kernel and rootfs (possibly
>> attached to the kernel) is very common. This can result in the
>> following order:
>>
>> (Target options)
>> Build options
>> Toolchain
>> System configuration
>> Kernel
>> Package selection for the target
>> Filesystem images
>> Bootloaders
>> Host Utilities
>> Legacy config options
>
> Hey! It looks good to me! :-)
> I'll handle this. Thanks!
>

Great!

>> By the way: isn't it more logical to put 'Bootloaders' in singular
>> (Bootloader), since one typically builds only one bootloader, just as
>> one only builds one kernel...
>
> This is two-sided:
>   - either you consider what Buildroot has to offer: one kernel, and
>     multiple bootloaders;
>   - or you consider what the user may want to install on the targe, at
>     most one kernel, and at most one bootloader.
>
> I prefer the first option. If at some point in the future Buildroot gets
> support for alternative kernels (GNU/Hurd, someone? ;-) ), then we'd
> have to s/Kernel/Kernels/.

Ok, agreed.

>
> Consequently, "Package selection for the target" should be a plural
> "Packages selection for target".

'Packages selection' sounds odd to me, I'm not even sure it's proper
English. A 'selection' always refers to a (potential) plural, so I
think 'Package selection' is more correct.

However, why such a long name? Is 'Target packages' not equally clear,
and more in line with the other menu names?

Best regards,
Thomas

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Thomas De Schampheleire]

On Thu, Aug 15, 2013 at 10:28 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
> Currently, all target options lie in the top-level menu.
> This looks a bit clumsy, since all other options are neatly
> folded into their own sematic sub-menus each.
>
> Move the target option into their own sub-menu too.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Fri, 16 Aug 2013 19:59:07 +0200, Yann E. MORIN wrote:

> This is two-sided:
>   - either you consider what Buildroot has to offer: one kernel, and
>     multiple bootloaders;
>   - or you consider what the user may want to install on the targe, at
>     most one kernel, and at most one bootloader.

"At most one bootloader" is wrong in many situations. On many ARM
platforms, you have two bootloaders. A small first stage bootloader,
and a full-featured second stage bootloader such as U-Boot or Barebox.

On AT91 platforms, you have AT91Bootstrap + U-Boot or Barebox.

On some i.MX platforms, you have mxs-bootlets + U-Boot or Barebox.

On some OMAP platforms, you have X-Loader + U-Boot.

etc, etc.

So clearly, we should keep "Bootloaders" in the plural form.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] targets: move target options to their own sub-menu

[Arnout Vandecappelle]

On 16/08/13 08:39, Yann E. MORIN wrote:
> Thomas, Arnout, All,
>
> On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
>> On Fri, Aug 16, 2013 at 1:10 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> On 15/08/13 22:28, Yann E. MORIN wrote:
>>>>
>>
>>>> diff --git a/arch/Config.in b/arch/Config.in
>>>> index 0b5b218..640926a 100644
>>>> --- a/arch/Config.in
>>>> +++ b/arch/Config.in
>>>> @@ -1,3 +1,5 @@
>>>> +menu "Target options"
>>>
>>>
>>>   I completely agree with the idea - especially in the xconfig, the big list
>>> of architecture options is extremely annoying. However, the menu title is
>>> not very clear. How about "Target architecture selection"? Or maybe
>>>
>>> Target CPU architecture
>>>
>>>    Target CPU architecture family
>>>
>>>    Target CPU architecture variant
>>>
>>
>> Well, I think the menu provides more than just the cpu architecture
>> choice. It includes other things like ABI choice, binary format
>> selection, and floating point strategy. The name 'target options' fits
>> better for these options than anything with 'target cpu architecture'
>> in it, but I'm open for other suggestions.
>
> Ditto.

  I would say that the ABI is part of the CPU architecture - you. An ABI 
choice only exists for compatibility with earlier or different variants 
of the same family. The ABI is typically defined by the CPU designer.

  Other choices in their are (or could be) floating point (neon/vfpv3), 
SIMD extensions, and in the future maybe SoC. All of which I would say 
are CPU architecture options.


>> While we're at reorganizing the top-level menu: I find the order of
>> the menus odd.
> [--SNIP--]
>> I think Bootloaders and Kernel should come earlier in the list and
>> reversed, and Host utilities should be after filesystem images.
>> My proposal is thus:
>> (Target options)
>> Build options
>> Toolchain
>> System configuration
>> Package selection for the target
>> Kernel
>> Bootloaders
>> Filesystem images
>> Host utilities
>> Legacy config options
>>
>> What is your opinion?
>
> I would even put the kernel before the packages, and bootloaders before
> kernel. Ie. I'd use the boot-time order of things:
>      (Target options)
>      Build options
>      Toolchain
>      System configuration
>      Bootloaders
>      Kernel
>      Packages selection
>      Filesystem images
>      Host Utilities
>      Legacy config options
>
> Bizzarely enough, moving bootloaders before kernel seems odd... :-/

  I started to write my own preferred order and it was still different 
:-) So I think there's simply no optimal order. That said, I certainly 
think that the kernel should come before the packages. So I'll ack your 
patch.


  Regards,
  Arnout

 >
>
> Regards,
> Yann E. MORIN.
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F