Skip to content

Introduce the _AVAILABLE mechanism

Thomas Petazzoni buildroot 1 version New

Get series with b4
b4 am 20121014125303.0c88e415@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

Yann,

Quoted 23 lines · Yann E. MORIN

This patch series is an RFC for how to handle the _AVAILABLE symbol in packages.

See this thread for the original proposal:

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

In this series, all packages are converted to use the _AVAILABLE symbol. My reasoning behind this is that:

1. all packages use the same mechanism, so they are consistent with each others
2. modifying a package (ie. adding new dependencies) is easy, and does not require tracking down all dependant packages
3. the dependencies of the comments "foo requires bar" are automatically updated in this case (although that's minor, and the comment themselves need updating)
4. with the new script in patch 2, it's dirt-easy to add a new package using the _AVAILABLE mechanism

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):

Quoted 6 lines
    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.

Sorry for not getting back to you earlier about this.

I am definitely in favour of this, and I'm really impressed by the methodology you've used to achieve this. I will post a few comments as replies to the individual patches with minor things.

However, I'd like you to update us on what are the remaining issues to be solved before being able to commit this (of course, the script needs to be re-executed to update all packages that have changed since you posted the patch series, but you seemed to mention other issues as well, gettext and maybe others).

Quoted 4 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?

Yes, we want this mechanism. Anyone trying to solve
http://autobuild.buildroot.org/results/3eaadd2365d60f574ba8daef45b34370cc5c6272/build-end.log
would agree with this change. I agree that it makes the simple package slightly more complicated, but not too much, so it sounds to me like it is a reasonable trade-off.

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