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

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

Closed
BenArtes opened this issue Jul 22, 2021 · 8 comments · Fixed by #245
Closed

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

BenArtes opened this issue Jul 22, 2021 · 8 comments · Fixed by #245

Comments

@BenArtes
Copy link

BenArtes commented Jul 22, 2021

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
@BenArtes BenArtes changed the title Blinky Example doesn't compile due to lack of LL Drivers Blinky Example doesn't compile due to lack of LL Components Jul 22, 2021
@atsju
Copy link
Collaborator

atsju commented Jul 22, 2021

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.

@atsju
Copy link
Collaborator

atsju commented Jul 22, 2021

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
Copy link
Author

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
Copy link
Author

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

@atsju
Copy link
Collaborator

atsju commented Jul 22, 2021

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

@atsju
Copy link
Collaborator

atsju commented Jul 22, 2021

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
Copy link
Author

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

@atsju
Copy link
Collaborator

atsju commented Jul 22, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants