Skip to content
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

cmake: dts: move to specifying shield on the command line #12403

Merged
merged 2 commits into from
Jan 18, 2019

Conversation

galak
Copy link
Collaborator

@galak galak commented Jan 9, 2019

Rather than specifying SHIELD via Kconfig, we move it to being specified
via the command line, similar to board.

Fixes #12102

@galak galak added the DNM This PR should not be merged (Do Not Merge) label Jan 9, 2019
@galak galak changed the title cmake: dts: move to specifying shield on the command line [RFC] cmake: dts: move to specifying shield on the command line Jan 9, 2019
@codecov-io
Copy link

codecov-io commented Jan 9, 2019

Codecov Report

Merging #12403 into master will decrease coverage by 4.08%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #12403      +/-   ##
==========================================
- Coverage   53.81%   49.73%   -4.09%     
==========================================
  Files         242      292      +50     
  Lines       27719    42433   +14714     
  Branches     6733     9969    +3236     
==========================================
+ Hits        14917    21102    +6185     
- Misses       9997    17180    +7183     
- Partials     2805     4151    +1346
Impacted Files Coverage Δ
misc/printk.c 84.93% <0%> (-2.09%) ⬇️
kernel/init.c 72.13% <0%> (-0.89%) ⬇️
kernel/timeout.c 86.11% <0%> (-0.26%) ⬇️
subsys/net/ip/tcp.c 56.93% <0%> (-0.13%) ⬇️
subsys/shell/shell_cmds.c 44.53% <0%> (ø) ⬆️
include/sys_clock.h 100% <0%> (ø) ⬆️
include/kernel.h 94.44% <0%> (ø) ⬆️
include/misc/gcov.h
boards/posix/nrf52_bsim/main.c 90.24% <0%> (ø)
subsys/bluetooth/controller/hci/hci_driver.c 67.32% <0%> (ø)
... and 62 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9707584...fef51e6. Read the comment docs.

Copy link
Member

@erwango erwango left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works fine, few comments plus following additions:

In samples/shields/x_nucleo_iks01a1/CMakeLists.txt:

# This sample is specific to x_nucleo_iks01a1 shield. Enforce -DSHIELD option
set(SHIELD x_nucleo_iks01a1)

Doc doc change required in doc/porting/shields.rst:

Shield activation
*****************

Activate support for a shield by adding the matching -DSHIELD arg to CMake
command

  .. zephyr-app-commands::
     :zephyr-app: your_app
     :gen-args: -DSHIELD=x_nucleo_iks01a1

samples/shields/x_nucleo_iks01a1/prj.conf Show resolved Hide resolved
samples/shields/x_nucleo_iks01a1/sample.yaml Outdated Show resolved Hide resolved
@galak galak requested a review from dbkinder as a code owner January 14, 2019 15:51
@erwango erwango dismissed their stale review January 14, 2019 15:52

I'm now pushing this change

@erwango erwango removed the DNM This PR should not be merged (Do Not Merge) label Jan 14, 2019
Copy link
Contributor

@dbkinder dbkinder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doc changes LGTM

@galak galak force-pushed the shield branch 4 times, most recently from 5e45e93 to dfe3839 Compare January 17, 2019 00:04
@galak galak changed the title [RFC] cmake: dts: move to specifying shield on the command line cmake: dts: move to specifying shield on the command line Jan 17, 2019
@galak
Copy link
Collaborator Author

galak commented Jan 17, 2019

@SebastianBoe can you take a look, I'm also trying to figure out how to export ${shield_list} to cmake/app/boilerplate.cmake, but can't figure out scope rules.

@SebastianBoe
Copy link
Collaborator

I need more information to be able to help you.

What seems to be the problem?

@galak
Copy link
Collaborator Author

galak commented Jan 18, 2019

I need more information to be able to help you.

What seems to be the problem?

I wanted to print ${shield_list} in the usage message, when I try to access it in cmake/usage/usage.cmake its empty.

@SebastianBoe
Copy link
Collaborator

I see.

usage.cmake is executed by it's own CMake process, see https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/usage/CMakeLists.txt#L5.

So it only has access to the variables that has been explicitly exported to it, see https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/usage/CMakeLists.txt#L6 for an example of exporting a variable to usage.cmake.

Also, usage.cmake is executed twice, so any additional variables must be applied both here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/usage/CMakeLists.txt#L6

and here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/extensions.cmake#L1114

@zephyrbot
Copy link
Collaborator

zephyrbot commented Jan 18, 2019

All checks are passing now.

Review history of this comment for details about previous failed status.
Note that some checks might have not completed yet.

@galak
Copy link
Collaborator Author

galak commented Jan 18, 2019

I see.

usage.cmake is executed by it's own CMake process, see /cmake/usage/CMakeLists.txt@master#L5.

So it only has access to the variables that has been explicitly exported to it, see /cmake/usage/CMakeLists.txt@master#L6 for an example of exporting a variable to usage.cmake.

Also, usage.cmake is executed twice, so any additional variables must be applied both here:

/cmake/usage/CMakeLists.txt@master#L6

and here:

/cmake/extensions.cmake@master#L1114

Ah thanks, that makes sense now.

@galak
Copy link
Collaborator Author

galak commented Jan 18, 2019

@SebastianBoe can you re-review the full PR. Should be complete now.

cmake/app/boilerplate.cmake Outdated Show resolved Hide resolved
cmake/app/boilerplate.cmake Outdated Show resolved Hide resolved

list(APPEND SHIELD_LIST ${shield})
if(DEFINED SHIELD)
if(${shield} STREQUAL ${SHIELD})
Copy link
Collaborator

@SebastianBoe SebastianBoe Jan 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With Kconfig, it was possible to enable multiple shields.

To retain this functionality we need to check if ${shield} is in the list ${SHIELD}.

... and possibly rename from SHIELD to SHIELDS.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would we specify multiple shields, as a 'space separated' list?

-DSHIELD="frdm_kw41z x_nucleo_iks01a1"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, CONF_FILE should be able to demonstrate how to do it if you see any problems.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, CONF_FILE should be able to demonstrate how to do it if you see any problems.

Ok, should now handle this case.

@galak galak force-pushed the shield branch 2 times, most recently from 45b55ec to 737f41e Compare January 18, 2019 15:20
Rather than specifying SHIELD via Kconfig, we move it to being
specified via the command line, similar to board.

So we can do:

  -DSHIELD=x_nucleo_iks01a1

or, for multiple shields:

  -DSHIELD="x_nucleo_iks01a1 frdm_kw41z"

Following cmake change, update x_nucleo_iks01a1 sample in order
not to enable CONFIG option anymore but set SHIELD cmake option.

Last, update documentation to reflect this change.

Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Following change of selection mechanism, clean boards/shields from
Kconfig related code.

Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
if(BOARD STREQUAL mimxrt1020_evk OR
BOARD STREQUAL mimxrt1050_evk OR
BOARD STREQUAL mimxrt1060_evk OR
BOARD STREQUAL frdm_k64f)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well that's unfortunate. :(

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually we are going to need something more sophisticated than CMake variables to give input to DT.

Like a separate Kconfig root/tree for DT for instance.

harness: bluetooth
extra_args: OVERLAY_CONFIG=overlay-shield_frdm_kw41z.conf
platform_whitelist: mimxrt1020_evk mimxrt1050_evk mimxrt1060_evk frdm_k64f
platform_whitelist: qemu_cortex_m3 qemu_x86 mimxrt1020_evk mimxrt1050_evk mimxrt1060_evk frdm_k64f
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of the modification to CMakeLists.txt, could you leave the two tests and set extra_args: SHIELD=frdm_kw41 in the second one?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead and merged this as I wanted to close on the base -DSHIELD support this week. I'll open a new PR for reworking the bluetooth test as you've asked in here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened PR #12585 for the BT Periph Sample change.

@galak galak merged commit 5a197bf into zephyrproject-rtos:master Jan 18, 2019
@galak galak deleted the shield branch January 18, 2019 19:22
masz-nordic added a commit to masz-nordic/zephyr that referenced this pull request Apr 3, 2019
After the rework in zephyrproject-rtos#12403, specifying a shield which has overlay
out of the tree causes unnecessary inclusions of overlays.
For every board root, overlays that have same index as
expected overlay are being included.
Fix this by removing already included overlays from SHIELD list.

Signed-off-by: Marcin Szymczyk <Marcin.Szymczyk@nordicsemi.no>
backporting bot pushed a commit that referenced this pull request Apr 17, 2019
After the rework in #12403, specifying a shield which has overlay
out of the tree causes unnecessary inclusions of overlays.
For every board root, overlays that have same index as
expected overlay are being included.
Fix this by removing already included overlays from SHIELD list.

Signed-off-by: Marcin Szymczyk <Marcin.Szymczyk@nordicsemi.no>
galak pushed a commit that referenced this pull request Apr 17, 2019
After the rework in #12403, specifying a shield which has overlay
out of the tree causes unnecessary inclusions of overlays.
For every board root, overlays that have same index as
expected overlay are being included.
Fix this by removing already included overlays from SHIELD list.

Signed-off-by: Marcin Szymczyk <Marcin.Szymczyk@nordicsemi.no>
nashif pushed a commit to nashif/zephyr that referenced this pull request May 7, 2019
After the rework in zephyrproject-rtos#12403, specifying a shield which has overlay
out of the tree causes unnecessary inclusions of overlays.
For every board root, overlays that have same index as
expected overlay are being included.
Fix this by removing already included overlays from SHIELD list.

Signed-off-by: Marcin Szymczyk <Marcin.Szymczyk@nordicsemi.no>
nashif pushed a commit that referenced this pull request May 7, 2019
After the rework in #12403, specifying a shield which has overlay
out of the tree causes unnecessary inclusions of overlays.
For every board root, overlays that have same index as
expected overlay are being included.
Fix this by removing already included overlays from SHIELD list.

Signed-off-by: Marcin Szymczyk <Marcin.Szymczyk@nordicsemi.no>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants