-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Refactor build-types for apps and samples #48
Comments
@TjazVracko See above, tell me what you think. This is definitely not the final form how should it be done, but a starting form. |
I like this in general. We have to bikeshed the hell out of the word "combination" though. |
I agree, I don't like it either, consider it as a placeholder name 😆 |
I have an additional idea which is kind of related to this. The selected build type should also be the value of |
Good idea, maybe we can pass it in just as EAST_BUILD_TYPE="dev", to not have any assumptions what is on the other end. |
So this is already done. Furthermore, we realized that it would be quite beneficial to make |
Context
Build type system does not cover one of the possible project configurations that came up in practical development. Due to that usage of build types is uncomfortable/non-convenient.
Problematic setup
Project is setup to build for two different boards:
nrf52840dk_nrf52840
native_posix
board, suitable for running on the development machineFor
nrf52840dk_nrf52840
board we want to have adev
build type, which uses debug KConfig options and RTT Kconfig options (RTT is used as logging and shell back-end), anddebug
build type, which used debug KConfig options.native_posix
board only needsdebug
build type.east.yml
for such setup would look something like this:The problem
With above config
east release
builds every possible west-board/build-type combination. This is not okay asnative_posix
does not support RTT, so you get a bunch of warnings when compiling for this combination.Basically, all possible build-types are not suitable for all west-boards.
Solution
Add a new
combinations
key, where each west-board defines its own list of possible build-types.There can be one or more west-boards, for each combination.
That way we can avoid the above situation.
In that case the
east.yml
should support something like this:The text was updated successfully, but these errors were encountered: