New direction for SOS v4?

[syntroniks]

I like where this repo is headed!

I have a suggestion for CMakeLists.txt that may be related to the comment in this macro --

CMakeSDK/SDK/CMakeLists.txt

Lines 40 to 44 in 56f4bc9

	macro(sdk_add_subdirectory NAME BRANCH)
	clone_or_pull(${NAME} ssh://git@github.com/StratifyLabs/${NAME}.git ${BRANCH})
	add_subdirectory(${BASE_DIRECTORY}/${NAME} ${NAME})
	# include(${CMAKE_CURRENT_SOURCE_DIR}/../${NAME}/library/${NAME}.cmake)
	endmacro()

I'd most likely be using forks of some of these libraries (potentially not on github). Perhaps as an alternative to sdk_add_subdirectory, we could use git submodules.

The advantage of sdk_add_subdirectory is pulling repos that are already cloned. I've used a submodule maintenance cmake script with some success: link here

Is this repo intended to be the next top-level? I could imagine forking and cloning this and having it bring in all dependencies (SOS, etc...) by way of submodules. Then building those via included cmake scripts rather than relying on the distributed toolchain.

Excited for v4!

[syntroniks]

I see this could also work by providing the git repo path to sdk_add_subdirectory

[tyler-gilbert]

This repo is basically going to be the CMake SDK files plus one example of how you could use CMake and git to manage your own SDK.

The /cmake folder has a collection of CMake files and routines to manage libraries, bsp's and applications. Those will serve as the basis for setting up the toolchain and some common variables.

The /SDK folder will serve as an example of how to get started. I would image people can fork this repo or just create their own /SDK repo to manage subprojects using either git submobules, cmake's ExternalProject module, or just ad-hoc clone and pull which is what I have right now.

If you have looked at https://github.com/StratifyLabs/API, you will see I am trying to migrate everything to modern cmake where you work directly with targets. Any of these projects will compile either as a top level project or as a subproject. It's working well for me now, as I can build all dependencies with a single command and I can either install them or just have the application be another subproject.

[syntroniks]

I have indeed looked at the new API repo.

Does this mean lines like

CMakeSDK/cmake/sdk/sos-sdk-app.cmake

Lines 41 to 44 in 06fb21d

	target_include_directories(${TARGET_NAME}
	PRIVATE
	${SOS_SDK_PATH}/Tools/gcc/include/StratifyOS
	)

are going away in favor of something else?

i.e. I see you forked newlib, are you moving away from hosting an archive of gcc+extras required to build SOS applications (desirable)?

[tyler-gilbert]

The basic approach is to use target_include_directories and the whole family of target_ functions. I need to think if those particular lines might be pushed to the user space or kept buried.

One of the big challenges is supported multiple build architectures for what is essentially the same target. That is most of the functionality of the cmake SDK--being able to make copies of a target for v7m vs v7em etc.

I do plan on having a CMake version of newlib. Newlib with autotools takes way too long to build. Using cmake it really just takes a few minutes. I have been using a modified version of newlib 2.3.0 for many years. Having it in its own repo will really help. I also have a compiler-rt repo that will replace libgcc. The last big challenge for bootstrapping a new compiler is rebuilding stdlibc++ with mlong-calls which I don't have a good solution for yet.

[tyler-gilbert]

As far as the StratifyOS repo goes, it will only have minor changes. Right now, it is entangled with StratifOS-mcu-stm32 and libraries like that in a few places and I want to remove those inter-dependencies (which will require changes to BSPs). I am also going to make a much better stack tracing routine that uses the frame pointer, add slabs to malloc(), and provide better configuration options (either compile time or link time).

[syntroniks]

I've wanted to rebuild stlibc++ as well for a freertos project.

It is good to hear about compiler-rt.

I'm trying to craft a pull request that might be valuable to you w.r.t. multi-platform. I can see where you're going with sos-sdk.cmake -- it reminds me a bit of the ESP-IDF SDK what with components and dependencies.

If you can weave the cmake files just right, the MCU package can provide variables like CMAKE_SYSTEM_NAME (Generic or StratifyOS, which cmake will use to look in a ../Platform/${CMAKE_SYSTEM_NAME} so you can specialize variables when building for StratifyOS) and CMAKE_SYSTEM_PROCESSOR and CMAKE_CXX_FLAGS.

Here's a snippet of my IMXRT1050-freertos.cmake:

if(IMXRT1050_FREERTOS_TOOLCHAIN_INCLUDED)
	return()
endif()
set(IMXRT1050_FREERTOS_TOOLCHAIN_INCLUDED true)

set(CMAKE_SYSTEM_NAME FreeRTOS)
set(CPU_NAME cortex-m7)
set(CPU_FLAGS "-mcpu=cortex-m7 -mthumb")
set(VFP_FLAGS "-mfloat-abi=hard -mfpu=fpv5-d16")
set(LD_FLAGS "--specs=nano.specs --specs=nosys.specs")

include(${CMAKE_CURRENT_LIST_DIR}/arm-none-eabi-gcc.cmake)

So anything strictly processor-specific will go there.

The (my) toolchain file for that project has this section:

#################
# System Config #
#################

if(NOT CMAKE_SYSTEM_NAME)
	set(CMAKE_SYSTEM_NAME Generic)
endif()
set(CMAKE_SYSTEM_PROCESSOR arm)
# Represents the name of the specific processor type, e.g. Cortex-M4
if(NOT CPU_NAME)
	set(CPU_NAME generic)
endif()

When it is included by the processor file, I have CPU_NAME cortex-m7 available in case things need to be specialized later on in the process.