[Buildroot] [PATCHv3 2/5] core: allow external Config.in/makefile code to be integrated

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Fri Nov 29 08:38:15 UTC 2013


Dear Yann E. MORIN,

On Thu, 28 Nov 2013 23:21:15 +0100, Yann E. MORIN wrote:

> > I perfectly understand what you mean, but I don't really like the idea
> > of sourcing BR2_EXTERNAL/package/Config.in.host, because it means the
> > user has to *always* create two Config.in files in its BR2_EXTERNAL
> > hierarchy to just get started in using BR2_EXTERNAL.
> > 
> > So, the reason your comment is *entirely* related to the previous
> > discussion is that in my previous proposal, I was including *ONE*
> > top-level BR2_EXTERNAL/Config.in, and it was up to the user to then do
> > whatever he wanted in this top-level Config.in file. We were not
> > enforcing anything.
> > 
> > I was OK with enforcing the usage of BR2_EXTERNAL/package/Config.in,
> > but not if we extend that to also enforce the usage (and existence) of
> > BR2_EXTERNAL/package/Config.in.host.
> 
> At first, I would have sided with Samuel on that one, since it might
> sound a bit ugly to have host packages appear in the target packages
> menu.
> 
> Yes, we want to enforce the directory layout in BR2_EXTERNAL. But do we
> want to enforce the menu structure. too?
> 
> In the end I think Thomas is right, but for different reasons: if we
> eventually added package/Config.in.host. then we should do the same for
> the bootloaders, too. And probably other menus, too. Which means the
> user would have to provide all of these files, even empty ones.
> 
> Anyway, let's keep it simple for now. We can refine it later if needed.

In other words, you're suggestion to revert back to the principle of
the v2 in terms of .mk file and Config.in inclusion? (I.e include a
top-level .mk file and top-level Config.in, and let the user do what he
wants?).

I personally believe this is the easiest and most flexible solution. We
can always state in the manual that we strongly recommend to keep a
directory structure similar to the one used in Buildroot. But at least
the user can organize its top-level menu as he sees fit (maybe even
using it to add board-specific config options, which we don't want in
Buildroot itself, but which a user may want for some reason).

The main improvement of v3 is the usage of the .br-external hidden
file, and this remains useful, so I'm really fine about reverting the
other part of v3 to what was done in v2 :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com



More information about the buildroot mailing list