Blinky Example doesn't compile due to lack of LL Components

Question

Blinky Example doesn't compile due to lack of LL Components

BenArtes opened this issue 3 years ago · comments

Describe the bug
When attempting to build the blinky example I receive the following error.

-- No STM32_TOOLCHAIN_PATH specified, using default: /usr
-- No STM32_TARGET_TRIPLET specified, using default: arm-none-eabi
-- The C compiler identification is GNU 6.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc
-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Neither STM32_CUBE_F4_PATH nor STM32_CMSIS_F4_PATH specified using default  STM32_CUBE_F4_PATH: /opt/STM32CubeF4
-- Found CMSIS: /opt/STM32CubeF4/Drivers/CMSIS/Include;/opt/STM32CubeF4/Drivers/CMSIS/Device/ST/STM32F4xx/Include (found version "5.4.0") found components:  STM32F4 
CMake Error at /home/terminus/stm32-cmake/cmake/FindHAL.cmake:220 (list):
  list sub-command REMOVE_DUPLICATES requires list to be present.
Call Stack (most recent call first):
  CMakeLists.txt:31 (find_package)

I presume that the lack of LL drivers in the blinky example causes list(REMOVE_DUPLICATES HAL_FIND_COMPONENTS_DRIVERS_LL) to fail.

I commented out the code as a test and then attempted to build blinky-ll and ran into similar errors related to HAL_FIND_COMPONENTS_DRIVERS.

I modified FindHAL.cmake to have checks surrounding the relevant blocks as below and all examples built correctly.

If this is a correct / desirable change I'm happy to create a pull request.

see #242

Environment (please complete the following information):

OS: Ubuntu 18.04
Compiler: arm-none-eabi-gcc (15:6.3.1+svn253039-1build1) 6.3.1 20170620
stm32-cmake: cebbda6

Julien Staub · Answer 1 · Thu Jul 22 2021 22:14:22 GMT+0800 (China Standard Time)

Thank you for reporting this issue.
I confirm blinky is compiling fine so maybe there is something system specific here.

Please do the PR as it will be easier to look at the diffs.

Julien Staub · Answer 2 · Thu Jul 22 2021 22:33:28 GMT+0800 (China Standard Time)

Ok I see what you mean. We will need to be able to reproduce the issue first.
What version of cmake are you using ?
What version of HAL are you using ?
Please confirm you did not modify the blinky example at all ?

BenArtes · Answer 3 · Thu Jul 22 2021 22:38:33 GMT+0800 (China Standard Time)

Using cmake 3.13.3 in terminal.

I just tested with cmake 3.19.2 that comes bundled with CLion and the issue does not occur.

HAL is STM32F4 (default).

Blinky was not modified.

BenArtes · Answer 4 · Thu Jul 22 2021 22:47:17 GMT+0800 (China Standard Time)

This looks like a change in behavior introduced in CMake 3.14: Release Notes, search for REMOVE_DUPLICATES.

Julien Staub · Answer 5 · Thu Jul 22 2021 22:55:52 GMT+0800 (China Standard Time)

Well done. I just found same reference and wanted to share link.

Julien Staub · Answer 6 · Thu Jul 22 2021 23:00:53 GMT+0800 (China Standard Time)

All tests are run an ubuntu 20.04 so after discussion with @Hish15 we will bump minium cmake version to 3.16.
We could fix you issue but because we do not test with cmake 3.13 there could be other masked problems.

BenArtes · Answer 7 · Thu Jul 22 2021 23:02:20 GMT+0800 (China Standard Time)

Makes sense. Ubuntu 18.04 is actually CMake 3.10. According to this table, Pinning at 3.13 really only adds Debian Buster.

Julien Staub · Answer 8 · Thu Jul 22 2021 23:05:56 GMT+0800 (China Standard Time)

Yes moreover if people were really using 3.13 you should not have been the first person to mention the problem. So I suppose it won't hurt too much.