Introduce the _AVAILABLE mechanism
Get series with b4
b4 am [email protected]Versions newest first
- 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.
Cover letter [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism
Quoted 3 lines · Thomas Petazzoni
In other words: we can assume the user knows about big subsystems (X.org, Python, Perl, etc.), but we don't want him to know the fine details of the dependencies on sub-options.
Someone (I don't remember who) proposed to stop doing that, because it adds
little value. Indeed, it's not as if 9 extra entries in the Scripting Languages menu will suddenly make it more difficult to navigate. Maybe X.org is an exception, but even there most packages are collected in the x11r7 menus (and those could still be kept in a conditional).
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'?
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 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