Skip to content

Introduce the _AVAILABLE mechanism

Thomas Petazzoni buildroot 1 version New

Get series with b4
b4 am 20121017213040.01b61869@skate

Versions newest first

  1. v1 Latest0 of 7 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 7 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism

Arnout,

Quoted 6 lines · Arnout Vandecappelle

Originally I was in favour of having the BR2_PACKAGE_PYTHON
conditionals, but it _would_ probably make life simpler if we only had dependencies on toolchain options...

Yann, what do you think, would it make suboption handling simpler
if there was no 'depends on BR2_PACKAGE_PYTHON'?

The real problem with _AVAILABLE is not caused by Python/X.org packages being under a big "if" condition. The big problem we hadn't really seen is that we don't only need to add _AVAILABLE options for each package, but also for each package sub-options that does a select on another package. This means that the number of _AVAILABLE kconfig options to add is a lot bigger than we expected, at a point that probably makes the _AVAILABLE solution relatively impractical.

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

Read the cover letter in its thread