| Message ID | 1418397665-28828-4-git-send-email-maxime.ripard@free-electrons.com |
|---|---|
| State | Rejected |
| Headers | show |
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
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
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
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(+)