[Buildroot] Question about external toolchain configuration "options"

[Buildroot] Question about external toolchain configuration "options"

[Grant Edwards]

When using an external toolchain, there are a bunch of toolchain 
toolchain "configuration options" in the buildroot .config file (e.g.
support for locale/i18n, wchar, ipv6, program_invokation, etc.).

However, these "options" don't really seem to be options.

There's only one correct choice for each, and buildroot figures out
what those correct choices are at build-time and aborts if the user
has picked the wrong values.

Why are they presented to the user as "choices" when the user doesn't
get to choose their values?  They only seem to be user-configurable
when building a toolchain.  When using an external toolchain, why not
just determine the correct values and do the build?

-- 
Grant Edwards               grant.b.edwards        Yow! My NOSE is NUMB!
                                  at               
                              gmail.com            

[Buildroot] Question about external toolchain configuration "options"

[Yann E. MORIN]

Grant, All,

On Tuesday 13 April 2010 20:30:21 Grant Edwards wrote:
> When using an external toolchain, there are a bunch of toolchain 
> toolchain "configuration options" in the buildroot .config file (e.g.
> support for locale/i18n, wchar, ipv6, program_invokation, etc.).
> 
> However, these "options" don't really seem to be options.
> 
> There's only one correct choice for each, and buildroot figures out
> what those correct choices are at build-time and aborts if the user
> has picked the wrong values.
> 
> Why are they presented to the user as "choices" when the user doesn't
> get to choose their values?  They only seem to be user-configurable
> when building a toolchain.  When using an external toolchain, why not
> just determine the correct values and do the build?
> 

Some packages depends on these 'options', so we have to know their values.
The packages are shown/hidden in the menuconfig.

To determine these 'options', we need to know the external toolchain location
first. The external toolchain location is also specified in the menuconfig.

So there is no way to detect those values, and properly show/hide the
affected packages.

Then there is two solutions:
- present toolchain 'options', and have proper package hidding, but implies
  checking the user did not make a mistake in the toolchain 'options',
or:
- present all packages, and then check that selected packages are buildable.

buildroot choosed the first solution. It has the advantage of using the
same package dependency rules as when using the built-in toolchain mechanism.

Maybe the prompts should be reworked with smthg like (when external toolchain
is selected):
  [ ] Toolchain has IPv6
  [ ] Toolchain has locales
and so on...

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] Question about external toolchain configuration "options"

[Thomas Petazzoni]

On Tue, 13 Apr 2010 20:51:47 +0200
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> wrote:

> To determine these 'options', we need to know the external toolchain location
> first. The external toolchain location is also specified in the menuconfig.
> 
> So there is no way to detect those values, and properly show/hide the
> affected packages.

Right.

> Then there is two solutions:
> - present toolchain 'options', and have proper package hidding, but implies
>   checking the user did not make a mistake in the toolchain 'options',
> or:
> - present all packages, and then check that selected packages are buildable.
> 
> buildroot choosed the first solution. It has the advantage of using the
> same package dependency rules as when using the built-in toolchain mechanism.

Exactly.

> Maybe the prompts should be reworked with smthg like (when external toolchain
> is selected):
>   [ ] Toolchain has IPv6
>   [ ] Toolchain has locales
> and so on...

This is what my toolchain-config-improvements branch does
(http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=toolchain-config-improvements),
but Peter had comments when I submitted it and I have ideas for
improvements.

I think I'll use some hidden options like :

config BR2_TOOLCHAIN_HAS_IPV6
	bool

All the packages should depend o n BR2_TOOLCHAIN_HAS_* options. And
then, internal toolchains configuration would do something like:

config BR2_BUILDROOT_TOOLCHAIN_ENABLE_IPV6
	bool "Enable IPv6 support"
	select BR2_TOOLCHAIN_HAS_IPV6

while external toolchain configuration would do something like:

config BR2_EXTERNAL_TOOLCHAIN_HAS_IPV6
	bool "Toolchain has IPv6"
	select BR2_TOOLCHAIN_HAS_IPV6

What do you think of this ?

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

[Buildroot] Question about external toolchain configuration "options"

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:


 Thomas> I think I'll use some hidden options like :

 Thomas> config BR2_TOOLCHAIN_HAS_IPV6
 Thomas> 	bool

 Thomas> All the packages should depend o n BR2_TOOLCHAIN_HAS_* options. And
 Thomas> then, internal toolchains configuration would do something like:

 Thomas> config BR2_BUILDROOT_TOOLCHAIN_ENABLE_IPV6
 Thomas> 	bool "Enable IPv6 support"
 Thomas> 	select BR2_TOOLCHAIN_HAS_IPV6

 Thomas> while external toolchain configuration would do something like:

 Thomas> config BR2_EXTERNAL_TOOLCHAIN_HAS_IPV6
 Thomas> 	bool "Toolchain has IPv6"
 Thomas> 	select BR2_TOOLCHAIN_HAS_IPV6

 Thomas> What do you think of this ?

That was my thought as well. Maybe reuse the existing symbols to limit
package churn.

-- 
Bye, Peter Korsgaard