Skip to contentSkip to conversation

targets: move target options to their own sub-menu

PATCH New Yann E. MORIN 4 participants 11 messages Aug 15, 2013 – Aug 19, 2013

lore
Share & tools
lore

Yann E. MORIN

author
#0 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

From: "Yann E. MORIN" <[email protected]>

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" <[email protected]>
---
 arch/Config.in | 4 ++++
 1 file changed, 4 insertions(+)
arch/Config.in +4 -0
index 0b5b218..640926a 100644
@@ -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
Signature · 1 line
1.8.1.2
#1 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

Quoted 18 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

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" <[email protected]>
---
  arch/Config.in | 4 ++++
  1 file changed, 4 insertions(+)
arch/Config.in +0 -0
index 0b5b218..640926a 100644

arch/Config.in line 1

Quoted 1 line
arch/Config.in +1 -0
@@ -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

Quoted 11 lines
arch/Config.in +3 -0
+
  config BR2_ARCH_IS_64
  	bool
 

@@ -324,3 +326,5 @@ endif
  if BR2_xtensa
  source "arch/Config.in.xtensa"
  endif
+
+endmenu # Target options
Signature · 6 lines
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
#2 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

Quoted 15 lines · Arnout Vandecappelle

arch/Config.in line 1

Quoted 8 lines · Yann E. MORIN
arch/Config.in +1 -0
index 0b5b218..640926a 100644
@@ -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

Quoted 6 lines

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

author
#3 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

Thomas, Arnout, All,

Quoted 20 lines · On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
Quoted 19 lines · Arnout Vandecappelle

arch/Config.in line 1

Quoted 8 lines · Yann E. MORIN
arch/Config.in +1 -0
index 0b5b218..640926a 100644
@@ -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

Quoted 8 lines
Quoted 2 lines

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.

Quoted 2 lines

While we're at reorganizing the top-level menu: I find the order of the menus odd.

[--SNIP--]

Quoted 14 lines

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

Quoted 1 line

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------'-------'------------------'--------------------'
#4 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

Quoted 19 lines · Yann E. MORIN

Thomas, Arnout, All,

Quoted 3 lines · On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
Quoted 2 lines · Arnout Vandecappelle
Quoted 1 line · Yann E. MORIN

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

Quoted 1 line

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

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

#5 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

Quoted 20 lines · Thomas De Schampheleire
Quoted 19 lines · Yann E. MORIN

Thomas, Arnout, All,

Quoted 3 lines · On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
Quoted 2 lines · Arnout Vandecappelle
Quoted 1 line · Yann E. MORIN

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

Quoted 5 lines
Quoted 1 line

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

author
#6 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

Thomas, All,

On 2013-08-16 12:30 +0200, Thomas De Schampheleire spake thusly:

Quoted 35 lines
Quoted 20 lines · Thomas De Schampheleire
Quoted 19 lines · Yann E. MORIN

Thomas, Arnout, All,

Quoted 3 lines · On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
Quoted 2 lines · Arnout Vandecappelle
Quoted 1 line · Yann E. MORIN

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

Quoted 5 lines
Quoted 1 line

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:

Quoted 10 lines

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

Quoted 3 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#7 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

Quoted 20 lines · Yann E. MORIN

Thomas, All,

On 2013-08-16 12:30 +0200, Thomas De Schampheleire spake thusly:

Quoted 6 lines

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:

Quoted 10 lines

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

Quoted 3 lines

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

Great!

Quoted 6 lines
Quoted 3 lines

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

Quoted 7 lines
    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.

Quoted 3 lines

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

#8 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

In reply to Yann E. MORIN

Dear Yann E. MORIN,

Quoted 5 lines · Yann E. MORIN

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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#9 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

In reply to Yann E. MORIN
Quoted 26 lines · Yann E. MORIN

Thomas, Arnout, All,

Quoted 23 lines · On Friday 16 August 2013 08:30:43 Thomas De Schampheleire wrote:
Quoted 21 lines · Arnout Vandecappelle

arch/Config.in line 1

Quoted 8 lines · Yann E. MORIN
arch/Config.in +1 -0
index 0b5b218..640926a 100644
@@ -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

Quoted 7 lines
Quoted 5 lines

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.

Quoted 32 lines
Quoted 2 lines

While we're at reorganizing the top-level menu: I find the order of the menus odd.

[--SNIP--]

Quoted 14 lines

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

Quoted 1 line

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

Quoted 1 line

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

Quoted 5 lines

Regards,
Yann E. MORIN.

Signature · 6 lines
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
#10 lore raw

PATCH 1/1 targets: move target options to their own sub-menu

In reply to Yann E. MORIN
Quoted 9 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

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" <[email protected]>
Acked-by Thomas De Schampheleire <[email protected]>