[Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Wed Oct 17 20:41:06 UTC 2012
Yann,
On Wed, 17 Oct 2012 22:16:43 +0200, Yann E. MORIN wrote:
> > From a quick review, it sounds sufficient indeed. What surprises me
> > is why we didn't think about this solution the other day when
> > discussing your _AVAILABLE patch set.
>
> To be honest, I'm surprised too I did not think about it. ;-]
>
> In fact, as an after-thought, I do know why. That's because I was
> thinking the other way-around: a package that depends on a sub-option
> of another package, sub-option which in turn depends on a third
> package. *That* one would require an _AVAILABLE for sub-options.
Aaah yes.
> For example, libuuid which is a sub-option of util-linux (although
> that one sub-option has no dpendency; but you get the idea) is select
> by a few other packages (eg. parted, ntfs-3g...).
>
> And going *that* route is IMHO not what we want.
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.
Except modifying kconfig, as we discussed, of course...
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the buildroot
mailing list