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

Although we'll discuss this at the BR devel day next Saturday, Yann won't be there
so we'd better have some discussion on the list as well (unless, Yann, you could be available on chat?).

On 09/10/12 01:40, Yann E. MORIN wrote:
[snip]

Quoted 10 lines

On the other hand, Arnout pointed out that only packages with depenencies on toolchain features should be converted, and in cascade, packages that depend on those, leaving alone packages that do not have any depednency at all (if I understood correctly):

     http://lists.busybox.net/pipermail/buildroot/2012-August/058040.html

Of course, no need to say I'm in favor of modifying all packages, if at least only for points 1&2 above. ;-) Of course, I understand Arnout's concerns about keeping simplicity and not adding cruft where it is not needed. This post is to request comments on this new deeply-impacting change.

With the pkg-new script, my concern is much reduced. The simplicity of having
the same pattern all over wins out in that case.

[snip]

Quoted 6 lines

Again, this series is an _RFC_ on the _AVAILABLE mechanism, so the first question we must answer is:

Do we even want this mechanism in buildroot at all?

Then, and only then, can we decide what to do, and how far to push it.

There is still an alternative: patch Kconfig to "properly" handle
select/depend transitivity. I.e., when a symbol selects another symbol, this implies that all dependencies of the other symbol are inherited. Did anyone ever investigate the feasibility of such an feature?

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