C++ / CMake broken for Smart Configurator

[saltyJeff]

When I create a new project using the RA Smart Configurator with C++ support enabled and the CMake option selected, the resulting CMakeLists.txt looks like this:

# You can call cmake from command line by toolchain file argument   use `-DCMAKE_TOOLCHAIN_FILE=cmake/gcc.cmake`

# Project minimum version
cmake_minimum_required(VERSION 3.16.4)

include(Config.cmake)

enable_language(C ASM)

# Project name
project(asdf VERSION 1.0.0)

include(${CMAKE_CURRENT_LIST_DIR}/cmake/GeneratedSrc.cmake)

C++ is not included in the enable_language, even though src/hal_entry.cpp is created

When I try to build, the compiler throws the following error:

'-std=c99' is valid for C/ObjC but not for C++

Because the output RASC_CMAKE_CXX_FLAGS is invalid.

Normally these settings wouldn't be an issue, but all the compiler flags are stored together into 1 giant string in cmake/GeneratedCfg.cmake, and it is a hassle having to filter out the useful flags (-mcpu -D_RA_CORE_) from the flags that I don't need (-Wxxx) and the flags that create a bunch of temporary makefiles.

[renesas-brandon-hussey]

Hi @saltyJeff which version of RASC and FSP are you using?

[saltyJeff]

Hi @saltyJeff which version of RASC and FSP are you using?

RASC version:

Smart Configurator

Version: 2022-10 (22.10.0)
Build Id: R20221013-1357

FSP version is 4.2.0

[renesas-andyb]

@saltyJeff - please can you try with RASC 2023-01, as shipped in FSP 4.3.0. I think this should resolve your issue.

[saltyJeff]

Hello @renesas-andyb we are currently looking at other mcu offerings so I may be slow to reply in the future.

Found another bug on v4.3.0, you're missing a SET(CMAKE_CXX_COMPILE_OBJECT "${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -c -o <OBJECT> -x c <SOURCE>") in gcc.cmake

I also noticed there's a new .vscode/ folder, can you please remove this as it conflicts with many of my pre-sets. If you do want to integrate with vscode-cmake, use the dedicated .vscode/cmake-kits.json instead of the settings file.

One final question, is there a way to make RASC generate code in release-mode? The CXX_FLAGS still has -g -O0 in the beginning which is set whether the build type is debug or release

[mbooth101]

Hi @saltyJeff

Hello @renesas-andyb we are currently looking at other mcu offerings so I may be slow to reply in the future.

Found another bug on v4.3.0, you're missing a SET(CMAKE_CXX_COMPILE_OBJECT "${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -c -o <OBJECT> -x c <SOURCE>") in gcc.cmake

Yes, I've found for some project types you may need to add

SET(CMAKE_CXX_COMPILE_OBJECT "${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -c -o <OBJECT> -x c <SOURCE>")
SET(CMAKE_CXX_LINK_EXECUTABLE "${CMAKE_LINKER} ${CMAKE_EXE_LINKER_FLAGS} -Wl,--start-group <OBJECTS> -Wl,--end-group")

to the gcc.cmake toolchain file. This is already fixed for the next release RASC 2023-04.

I also noticed there's a new .vscode/ folder, can you please remove this as it conflicts with many of my pre-sets. If you do want to integrate with vscode-cmake, use the dedicated .vscode/cmake-kits.json instead of the settings file.

Aha, thanks for the hint; I'm still very new to VSCode. I will see what options we can move over into that file. In the meantime it should be safe to move the settings.json if you wish -- RASC will not try to regenerate it.

One final question, is there a way to make RASC generate code in release-mode? The CXX_FLAGS still has -g -O0 in the beginning which is set whether the build type is debug or release

Not yet, but I will raise this internally. Support for the other IDEs does include generation of both Debug and Release configurations, so I think this is definitely a deficiency in CMake project generation.

[liux-pro]

hi @mbooth101
This line did show up in RASC 2023-04, but it is not correct. The -x option in GCC is used to explicitly specify the programming language of the input source file. So this line is force gcc trade c++ file as c when compile c++. It should be -x c++

SET(CMAKE_CXX_COMPILE_OBJECT "${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -c -o <OBJECT> -x c <SOURCE>")

[liux-pro]

There's a line in GeneratedCfg.cmake

SET(RASC_CMAKE_CXX_FLAGS "-g -O0 -mcpu=cortex-m23 -I ${CMAKE_CURRENT_SOURCE_DIR}/ra/arm/CMSIS_5/CMSIS/Core/Include -I ${CMAKE_CURRENT_SOURCE_DIR}/ra/fsp/inc -I ${CMAKE_CURRENT_SOURCE_DIR}/ra/fsp/inc/api -I ${CMAKE_CURRENT_SOURCE_DIR}/ra/fsp/inc/instances -I ${CMAKE_CURRENT_SOURCE_DIR}/ra_cfg/fsp_cfg -I ${CMAKE_CURRENT_SOURCE_DIR}/ra_cfg/fsp_cfg/bsp -I ${CMAKE_CURRENT_SOURCE_DIR}/ra_gen -I ${CMAKE_CURRENT_SOURCE_DIR}/src  -D_RA_CORE=CM23  -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wshadow -Wlogical-op -Waggregate-return -Wfloat-equal -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -mthumb  -std=c99 -MMD -MP -MF <SOURCE>.d -MT <OBJECT>")

Why all include dir is hard-coded here, and the target_include_directories in GeneratedSrc.cmake do NOT work at all after my test.

[liux-pro]

In file gcc.cmake

SET(CMAKE_LINKER ${CMAKE_FIND_ROOT_PATH}/arm-none-eabi-gcc${BINARY_FILE_EXT})

When build c++ project, linker shoule be set to arm-none-eabi-g++

[renesas-brandon-hussey]

Fixes for these issues are currently scheduled for the e2 studio 2024-04 release which should align with the FSP v5.3.0 release.