alternate cmake-based build system (STM32 HAL)

[ponyatov]

Will it be a good or bad idea about

• making alternate cmake-based build system and
• using cmake presets for target configuring?

What I don't like in current pythonic configurator is all the pile of target details and options was spread around more or less large .py scripts.

I want to make Espruino to be more modular, at least totally split the JS core from hardware- and config-specific components, and made some API for generic BSP to link JS core with hw and platform-specific libraries.

The first step I want to implement is using separated BSP packages for STM32 chips generated by CubeMX configuration. Also, it includes some code refreshing using HAL in platform-related code.

[gfwilliams]

Hi,

What are the actual benefits of a cmake-based config?

Because my concern is every HAL I've come across tends to want to 'own' the build process - be that Nordic, ST, Raspberry Pi, Espressif, etc. Trying to come up with a system that actually works for all of those without a massive hack seems almost impossible.

I imagine you'd make a new build system for your specific project with ST, it'd be incompatible with everything else, and I imagine you're probably not in a position to make it work with all the other targets.

The first step I want to implement is using separated BSP packages for STM32 chips generated by CubeMX configuration

The issue here as far as I know is CubeMX wants to hard-code the locations of all the on-chip peripherals, which is the exact opposite of what Espruino wants to do where you can choose what peripherals go where in JS?

and made some API for generic BSP to link JS core with hw and platform-specific libraries.

That's what the API in jshardware.c does surely?

So if you want to do your CubeMX thing, the best bet is to make your own folder under targets/myproject, add your own jshardware.c and main.c and work from there?

[fanoush]

as for cmake, isn't the ESP32 build doing something similar? first Espruino make will run the python stuff and generate Espruino specfic sources including cmake files for the target and then cmake can be run in the way vendor expects it to be run?

I didn't look into details too much but hoped it could be reused for RP2040/2350 in future and possibly also for this case?

[gfwilliams]

and then cmake can be run in the way vendor expects it to be run?

Yes, ESP32_IDF4 does this at https://github.com/espruino/Espruino/blob/master/make/targets/ESP32_IDF4.make

I'd be very happy to have that code pulled out into something more generic that could be used for more platforms. Using that for RP2040 would be great - I know @jumjum123 has put a bunch of work into the port (https://github.com/jumjum123/Espruino4Pico) but it's been hard to pull it back upstream because of the change in build system.