[Buildroot] BR2_EXTERNAL - Broken in 2015.08.01????
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Fri Nov 6 14:41:02 UTC 2015
Dear Stephen Beckwith,
On Fri, 6 Nov 2015 09:12:50 -0500, Stephen Beckwith wrote:
> Referencing Slide 232 - it states: “recommended structure” - and this
> shows a structure beginning with <board> - hence my earlier question about
> directory naming.
Recommended != Mandatory.
It is not because we *recommend* a certain structure that all aspects
of this *recommended* structure are *mandatory*.
And indeed, the board/ directory is not *mandatory*, it's a pure
suggestion.
> Referencing the Manual, Section 9.1.1 - Implemeting layered
> customizations. I reviewed this, since in my setup, I will have what would
> be considered a “layered” setup: A common directory with ~ 75 packages,
> directories for “platform” specific items, and then directories with items
> from specific vendors that need to be included in the overall system.
OK. There's no question in this paragraph, so I assume you're just
giving some context. So far, everything looks right.
> So based upon Section 9.1.1 - there is no “package” directory here, which
> contradicts your “must” list for the naming conventions.
Section 9.1.1 only shows an example organization for the board/
directory, in which we recommend to store things like rootfs overlays,
post-build scripts, Linux kernel configuration files, etc.
Nowhere is section 9.1.1 talking about packages.
Moreover, I never said that you *must* have a package/ directory in
your BR2_EXTERNAL. *If* you have packages to implement in your
BR2_EXTERNAL then we *recommend* to put their description in package/,
in order to mimic the organization of Buildroot itself.
> - Does each package need to be in a separate “package/xyz”
> directory or can there be a single package directory with multiple
> sub-directories for each package? Refer to Slide 232.
package/ is just a suggestion, and you can organize it whichever way
you want. Buildroot does not enforce anything in that respect. There
can be sub-directories, just like we have sub-directories for certain
packages in Buildroot itself.
So something like:
+ Config.in
+ external.mk
+ package
+ foo1
+ foo1.mk
+ Config.in
+ vendor1
+ vendor1.mk
+ vendor1-app1
+ vendor1-app1.mk
+ Config.in
+ vendor1-app2
+ vendor1-app2.mk
+ Config.in
is perfectly fine. Of course, you have to make sure that external.mk
includes package/*/*.mk, and that vendor1.mk includes
package/vendor1/*/*.mk. See the numerous examples of this available in
Buildroot proper.
> 1) So all the Config.in files must follow the following convention:
> BR2_EXTERNAL_<PACKAGE>?
No. Please read the documentation again. The Config.in options for
packages *must* be named BR2_PACKAGE_<pkg>
> 2) I can use BR2_EXTERNAL_<PACKAGE> in the foo.mk to clarify make
> options, yes?
I don't see why you need BR2_EXTERNAL_<PACKAGE> to clarify anything in
the .mk files.
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