Skip to content

Introduce the _AVAILABLE mechanism

Arnout Vandecappelle buildroot 1 version New

Get series with b4
b4 am [email protected]

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
Quoted 9 lines · Thomas Petazzoni

Our example was the one of python-dpkt, which was doing a:

depends on BR2_PACKAGE_PYTHON
select BR2_PACKAGE_PYTHON_ZLIB

or BR2_PACKAGE_PYTHON_ZLIB is not a package per-se, but a sub-option of the python package. And this this sub-option does a select, we should introduce a BR2_PACKAGE_PYTHON_ZLIB_AVAILABLE, I don't see a way around it.

It is still possible to add an _AVAILABLE for sub-options that need them.
For something like a python module, it does make sense have an _AVAILABLE for the sub-option. Similar for GStreamer modules using an external library. These things can be considered a separate (micro)package, in some sense.

If the script converts the python-dpkt example above into
depends on BR2_PACKAGE_PYTHON_ZLIB_AVAILABLE
select BR2_PACKAGE_PYTHON_ZLIB
won't kconfig detect that PYTHON_ZLIB_AVAILABLE doesn't exist? Then it will be easy enough to fix those suboptions manually (if there aren't too many of them...).

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

Read the cover letter in its thread