load board config again to allow overwrite family config

[hzyitc]

Description

The board config is only contain some variable assignments, so it should be safe to be sourced twice. If it doesn't, we can fix easily.

With this, we can overwrite the family config. So we don't need to check BOARD in family config ( e.g. the u-boot config ) . Just define it in board config.

How Has This Been Tested?

[ ] Build and run test for all board

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[igorpecovnik]

@rpardini This is another NEXT topics :) We used to have this override and once we let it go. In NEXT?

[mhoffrog]

This is another NEXT topics :) We used to have this override and once we let it go. In NEXT?

Including a script twice in different stages of the build is raising another level of confusion and hidden dependencies.
So just as a draft thinking I would prefer this re-design to be something like:

1. include the board script only once within config-prepare.sh - as is today
2. Let the board script provide two functions - like e.g.:
   a) board_pre_main_config() - this one will be called from config-prepare.sh right after including board script
   b) board_post_main_config() - this will be called appropriately after any familiy and/or common scripts have been included from the place you did locate the second source including of this PR.

For backward compatibility we should check the existence of those functions and log a warning, if those are not there to motivate for according re-factoring of the board scripts over time.

[hzyitc]

I don't think spilting into two parts is a good idea.

1. If a variable is defined in pre, when someone try to add this variable in family config, he can't known that some board config will be overwrite.
2. If we need to overwrite a function, we need to define this function in a function, which is really strange.

The first include only require one varable - BOARDFAMILY.

So if we refactor, we can group the boards in folder which named as its family. So we can solve this problem and make struct more clean.

[mhoffrog]

So if we refactor, we can group the boards in folder which named as its family. So we can solve this problem and make struct more clean.

Sounds good to me as well - the simpler the better!

[rpardini]

Folks, we've the extensions mechanism to address this and others.
Example:

build/config/boards/orangepi5.wip

Lines 17 to 22 in e9fea8a

	# Override family config for this board; let's avoid conditionals in family config.
	function post_family_config__orangepi5_use_vendor_uboot() {
	BOOTSOURCE='https://github.com/orangepi-xunlong/u-boot-orangepi.git'
	BOOTBRANCH='branch:v2017.09-rk3588'
	BOOTPATCHDIR="legacy"
	}

Docs (a bit outdated): https://docs.armbian.com/Developer-Guide_Extensions/

armbian-next has a few more hooks (mostly cosmetical stuff, to avoid using case / if for BRANCH etc) but it's mostly the same.

[mhoffrog]

Docs (a bit outdated): https://docs.armbian.com/Developer-Guide_Extensions/

plus https://docs.armbian.com/Developer-Guide_Extensions-Hooks/

[igorpecovnik]

Lets rather move this to extensions.

[igorpecovnik]

Still relevant?