Zephyr: samples/sensor/apds9960/ results into build failure on multiple platforms.

[yerabolu]

The test samples/sensor/apds9960/ results into build failure on multiple platforms.

Board: sam_e70_xplained, quark_d2000_crb, quark_se_c1000_devboard, quark_se_c1000_ss_devboard
Arch: x86, arm, arc
Zephyr version: commit 98d765a3b4c6204cd789754ff266cf53791d570f.
Toolchain: ZEPHYR_TOOLCHAIN_VARIANT=zephyr

Build Log:

[1/109] Preparing syscall dependency handling

[15/109] Building C object CMakeFiles/app.dir/src/main.c.obj
FAILED: CMakeFiles/app.dir/src/main.c.obj
ccache /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc -DBUILD_VERSION=zephyr-v1.13.0-612-gd332ae5 -DKERNEL -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I/home/pswarnak/workspace/clean_zephyr/zephyr/kernel/include -I/home/pswarnak/workspace/clean_zephyr/zephyr/arch/arm/include -I/home/pswarnak/workspace/clean_zephyr/zephyr/soc/arm/atmel_sam/same70 -I/home/pswarnak/workspace/clean_zephyr/zephyr/soc/arm/atmel_sam/same70/include -I/home/pswarnak/workspace/clean_zephyr/zephyr/soc/arm/atmel_sam/include -I/home/pswarnak/workspace/clean_zephyr/zephyr/boards/arm/sam_e70_xplained -I/home/pswarnak/workspace/clean_zephyr/zephyr/include -I/home/pswarnak/workspace/clean_zephyr/zephyr/include/drivers -Izephyr/include/generated -isystem /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/lib/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/include -isystem /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/lib/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/include-fixed -I/home/pswarnak/workspace/clean_zephyr/zephyr/lib/libc/minimal/include -I/home/pswarnak/workspace/clean_zephyr/zephyr/soc/arm/atmel_sam/common/. -I/home/pswarnak/workspace/clean_zephyr/zephyr/ext/hal/atmel/asf/sam/include/same70 -I/home/pswarnak/workspace/clean_zephyr/zephyr/ext/hal/cmsis/Include -Os -g -Wall -Wformat -Wformat-security -Wno-format-zero-length -imacros /home/pswarnak/workspace/clean_zephyr/zephyr/samples/sensor/apds9960/build/zephyr/include/generated/autoconf.h -ffreestanding -Wno-main --sysroot /opt/zephyr-sdk/sysroots/armv5-zephyr-eabi/usr -mthumb -mcpu=cortex-m7 -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -Wno-pointer-sign -Wno-unused-but-set-variable -fno-reorder-functions -fno-defer-pop -Werror=implicit-int -Wpointer-arith -ffunction-sections -fdata-sections -mabi=aapcs -std=c99 -MD -MT CMakeFiles/app.dir/src/main.c.obj -MF CMakeFiles/app.dir/src/main.c.obj.d -o CMakeFiles/app.dir/src/main.c.obj   -c ../src/main.c
../src/main.c: In function ‘main’:
../src/main.c:32:27: error: ‘CONFIG_APDS9960_DRV_NAME’ undeclared (first use in this function)
  dev = device_get_binding(CONFIG_APDS9960_DRV_NAME);
                           ^~~~~~~~~~~~~~~~~~~~~~~~
../src/main.c:32:27: note: each undeclared identifier is reported only once for each function it appears in
[24/109] Building C object zephyr/CMakeFiles/zephyr.dir/soc/arm/atmel_sam/same70/soc.c.obj
ninja: build stopped: subcommand failed.
[pswarnak@localhost build]$ pwd
/home/pswarnak/workspace/clean_zephyr/zephyr/samples/sensor/apds9960/build

Steps to reproduce:

cd zephyr/samples/sensor/apds9960/
rm -rf build && mkdir build && cd build
cmake -D BOARD=sam_e70_xplained -GNinja ../
ninja

Check the build log.

Additional info:
The DTS related changes results into failure of multiple sensor test cases such as hts221, apds9960 and others.

[MaureenHelm]

What boards should this sample be buildable for? The only board mentioned in samples/sensor/apds9960/sample.yaml is the reel_board, thus CI passed.

[nashif]

What boards should this sample be buildable for? The only board mentioned in samples/sensor/apds9960/sample.yaml is the reel_board, thus CI passed.

this should work for any board that has this sensor connected, the sanitycheck configuration was set to limit the rebuilds of the sample.

If we are to add overrides for each board that is going to be a mess, we need to find a better way to allow this type of configuration maybe proving a generic override file instead of for each board.

[MaureenHelm]

The only in-tree board that has this sensor connected is the reel_board. Any other board requires a shield or blue wires. I don't know how you can have a generic override file when you have to manually wire up the sensor to the board.

[pswarnak]

@MaureenHelm
I think the expectation here is to make sure build works fine. However, for test case to pass runtime, we definitely need the sensor connected on the board.
Prior to dts related changes, the test case was able to build properly for quark_d2000_crb and/or sam_e70_xplained. Also, the build failure is not only in apds9960 sensor test case. It fails even for hts221 where no platform_whitelist is mentioned.
So, my understanding is that build should pass for the hardware boards that defines particular sensor driver. Please provide your inputs.

[MaureenHelm]

So, my understanding is that build should pass for the hardware boards that defines particular sensor driver.

I argue that most boards don't have this particular sensor hardware and thus the sample is not valid for those boards. The same is true for hts221, except we are using depends_on/supports attributes instead of a platform_whitelist to choose which boards the sample is valid for.

[spoorthik]

@MaureenHelm: I agree that most boards don't have sensor embedded but sensor can always be connected if the board supports particular sensor driver. So ideally, build should pass for any board with sensor driver support.

@nashif: We should have attributes in yaml file to filter out platforms which supports particular sensor driver (like depends_on: hts221 in hts221 sample.yaml) and have fixture enabled to check if sensor is actually connected, to make any sensor samples work. But currently we are filtering out boards using platform whitelist instead. So, having depends_on: <sensor driver> would be right approach. Don't you think so?

[galak]

@nashif: We should have attributes in yaml file to filter out platforms which supports particular sensor driver (like depends_on: hts221 in hts221 sample.yaml) and have fixture enabled to check if sensor is actually connected, to make any sensor samples work. But currently we are filtering out boards using platform whitelist instead. So, having depends_on: <sensor driver> would be right approach. Don't you think so?

I think we've done that for various sensors at this point. An example is lsm6dsl. We aren't consistent with it today. In the future we use the DTS compat to filter on.

However, I don't think we are going to make tests/samples build if the hardware isn't present in the dts.