[OpenWrt-Devel,RFC,3/5] target: Add board notion support
diff mbox

Message ID 1418397665-28828-4-git-send-email-maxime.ripard@free-electrons.com
State Rejected
Headers show

Commit Message

Maxime Ripard Dec. 12, 2014, 3:21 p.m. UTC
Even though we always build all the board images for a given target, some
options widely differ from one board to another when it comes to hardware
configuration.

Such an option for example is the NAND setup, which depends on the NAND chip
itself, that obviously varies from one board to another.

This kind of options used to be declared either globally for one platform,
which would enforce a fragile default, or through alternate profiles, that
would result in an unusable image that would still be compiled if we chose the
wrong one.

Introduce a new notion of boards, that would be defined in the
$(PLATFORM_DIR)/boards directory, to set up this kind of board specific
options, that we always want to be in-use, no matter what profile is used.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 include/target.mk | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Felix Fietkau Dec. 16, 2014, 9:15 a.m. UTC | #1
On 2014-12-12 16:21, Maxime Ripard wrote:
> Even though we always build all the board images for a given target, some
> options widely differ from one board to another when it comes to hardware
> configuration.
> 
> Such an option for example is the NAND setup, which depends on the NAND chip
> itself, that obviously varies from one board to another.
> 
> This kind of options used to be declared either globally for one platform,
> which would enforce a fragile default, or through alternate profiles, that
> would result in an unusable image that would still be compiled if we chose the
> wrong one.
> 
> Introduce a new notion of boards, that would be defined in the
> $(PLATFORM_DIR)/boards directory, to set up this kind of board specific
> options, that we always want to be in-use, no matter what profile is used.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The current image building code and the various hacks that different
platforms use to match images to profiles is a complete mess.
I've started implementing a new set of templates for declaring images,
which will be simpler, more coherent and will allow better control over
which images will be built with which subtarget/profile. It will also
support parallel building.
I would like to avoid adding more API stuff that depends on the current
bad design. Since this patch seems to be adding nothing but a simple
include statement and a wrapper for appending stuff to a variable, I'd
like to leave it out and open code that stuff in the target image
makefile instead, until the new image code is ready.

- Felix
Maxime Ripard Dec. 19, 2014, 10:59 a.m. UTC | #2
Hi Felix,

On Tue, Dec 16, 2014 at 10:15:41AM +0100, Felix Fietkau wrote:
> On 2014-12-12 16:21, Maxime Ripard wrote:
> > Even though we always build all the board images for a given target, some
> > options widely differ from one board to another when it comes to hardware
> > configuration.
> > 
> > Such an option for example is the NAND setup, which depends on the NAND chip
> > itself, that obviously varies from one board to another.
> > 
> > This kind of options used to be declared either globally for one platform,
> > which would enforce a fragile default, or through alternate profiles, that
> > would result in an unusable image that would still be compiled if we chose the
> > wrong one.
> > 
> > Introduce a new notion of boards, that would be defined in the
> > $(PLATFORM_DIR)/boards directory, to set up this kind of board specific
> > options, that we always want to be in-use, no matter what profile is used.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> The current image building code and the various hacks that different
> platforms use to match images to profiles is a complete mess.

We do agree on that.

> I've started implementing a new set of templates for declaring images,
> which will be simpler, more coherent and will allow better control over
> which images will be built with which subtarget/profile. It will also
> support parallel building.

Cool!

> I would like to avoid adding more API stuff that depends on the current
> bad design. Since this patch seems to be adding nothing but a simple
> include statement and a wrapper for appending stuff to a variable, I'd
> like to leave it out and open code that stuff in the target image
> makefile instead, until the new image code is ready.

Well, it was more of an RFC. It was mostly to test if the approach
itself was okay. There's indeed some flaws in the implementation, I
would have liked to move all the board iteration in the common build
stuff for example.

But if you have something that would work in a similar way, or at
least with a similar goal, then yes, it seems better.

Maxime

Patch
diff mbox

diff --git a/include/target.mk b/include/target.mk
index db501e06c760..b6d1c9fde9bf 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -87,6 +87,12 @@  define Profile
 endef
 endif
 
+ifndef Board
+define Board
+  TARGET_BOARDS += $(1)
+endef
+endif
+
 ifneq ($(PLATFORM_DIR),$(PLATFORM_SUBDIR))
   define IncludeProfiles
     -include $(sort $(wildcard $(PLATFORM_DIR)/profiles/*.mk))
@@ -98,11 +104,17 @@  else
   endef
 endif
 
+define IncludeBoards
+  -include $(sort $(wildcard $(PLATFORM_DIR)/boards/*.mk))
+endef
+
 ifeq ($(TARGET_BUILD),1)
   $(eval $(call IncludeProfiles))
+  $(eval $(call IncludeBoards))
 else
   ifeq ($(DUMP),)
     $(eval $(call IncludeProfiles))
+    $(eval $(call IncludeBoards))
   endif
 endif