[Buildroot] [PATCH 2/2] linux: fix use of extensions

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Fri Mar 13 22:31:11 UTC 2015

Dear Yann E. MORIN,

On Fri, 13 Mar 2015 23:10:13 +0100, Yann E. MORIN wrote:

> > Hum, I am not sure to see why the switch to the kconfig-package
> > infrastructure would have modified this behavior. So I'd like to
> > understand how it used to work, if it ever worked (but I believe it
> > did, no?).
> Fair enough, I'll double-check that it did / did not work back then.


> > This is a bit problematic because then the dependency is unknown to the
> > package infrastructure. Which means that things like 'make
> > graph-depends' will no longer display this dependency.
> Right. Note however that this was already the case for the RTAI
> externsion, because it was declaring:
>     LINUX_DEPENDENCIES += rtai-patch
> so that was already missed (or at least mis-interpreted) by graph-depends
> anyway.

Indeed, correct. And that's not nice :/

> > I'm not sure to understand how the linux extensions had to delve into
> > the .stamp_patched internals. They were just registering a
> > POST_PATCH hook, no?
> No, they _did not_ have to so far.
> What I meant is that the switch to a dependency of the patch step
> required that they would now all have had to write something like:
>     $(LINUX_DIR)/.stamp_patched: | EXT-patch
> (where EXT is the name of the extension.)
> To avoid such an arcane code that would have to be replicated (and
> potentially tracked down in case we change something in dependency
> handling), I found it would be better to have it all handled in a single
> location.

Ok, understood.

> Anyway, I'll look at your suggestion of introducing FOO_PATCH_DEPENDENCIES.
> However, linux is the sole package that requires such handling, and I
> wonder if it is worth introducing for just a single package (note that
> I rehash your own argument, hehe! ;-) )

Point taken :-)

But my argument about putting things in the infra only if at least a
significant number of packages need it is only valid if there's another
way of doing it that works. For example, if you have three packages
that do --disable-foobar, then it's not a strong argument to put it in
the infra because it can perfectly be done in a per-package fashion.

However, things such making sure that the infra is aware of weird
dependencies is not something you can fix at the per-package level, you
need some support from the infrastructure.

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering

More information about the buildroot mailing list