Porting TGUI to a new operating system

[sgnAudio]

Dear,

TGUI looks very interesting. What steps would be needed to port it to a new OS? I would like to use it on a ESP32, 32MB Ram, dual 400MHz cores, what has already a somehow POSIX like operating system, based on FreeRTOS, with file system, multi-threading ect, and a SDL 3 port. 

I saw Config.hpp.in, can all modifications made in there? I did not see a porting guide, such a document would be great.

Best regards,
Michael

[texus]

I honestly have no idea how feasible it is to port it to such system.
If SDL3 already works, then technically it should be possible if you have a working c++17 compiler. I'm more concerned about the available RAM though, TGUI is not optimized at all for low memory usage. So I'm concerned that the gui will use too much RAM for such a system.

Do you know how to cross-compile for the ESP32 with CMake? TGUI relies on CMake as build system, so if CMake is supported when building for ESP32 then it would be significantly easier to port.

The two places that I know that might need changes to OS detection are https://github.com/texus/TGUI/blob/1.x/cmake/Config.cmake#L1 and https://github.com/texus/TGUI/blob/1.x/include/TGUI/Config.hpp.in#L35
Initially I would just define TGUI_SYSTEM_LINUX/TGUI_OS_LINUX and see how far the compilation gets. If you get errors because about missing Linux stuff then you could try looking for workarounds, but if it's POSIX then maybe most just works (TGUI does very little platform-specific things).

[sgnAudio]

Thanks for your prompt answer.

The C++ compiler supports the C++23 standard with the GNU extensions (-std=gnu++23) by default. The build system is based on CMake to configure the project, manage components, and generate build files for tools like Ninja, which is then used to build the project. The idf.py command-line tool provides a user-friendly interface that manages the CMake build process.

So far so good. Let me try, how far I come with the memory limit.

[texus]

I created a minimal example with esp-idf that had the following in the "main" directory.
The test.c file was practically empty and the TGUI sources where copied into main/TGUI.

Code (cmake) Select Expand

# "Enable C++ exceptions" and "Enable C++ run-time type info (RTTI)" must be checked in menuconfig
idf_component_register(SRCS test.cpp
                       INCLUDE_DIRS ".")

set(TGUI_BACKEND "Custom")
set(CMAKE_SYSTEM_NAME "Linux")
set(BUILD_SHARED_LIBS OFF)
set(TGUI_INSTALL OFF)
add_subdirectory(TGUI)

target_link_libraries(${COMPONENT_LIB} PUBLIC TGUI::TGUI)

One change that had to be made in the TGUI sources was to remove the "target_link_libraries(tgui PRIVATE ${CMAKE_DL_LIBS})" line in TGUI/src/CMakeLists.txt.
I imagine that this could cause linking issues later with the code in FileDialogIconLoaderLinux.cpp, so maybe that code might need to be removed later as well.

The "idf.py build" command succeeds like this, and it seems to have compiled TGUI in the process (because it threw a lot of errors initially before I enabled exceptions and RTTI). This is as far as I'll be able to build myself, the next steps will be up to you. But feel free to ask if you encounter specific errors about the TGUI code later.

The TGUI_BACKEND will still have to be changed to use SDL as well once you can get a minimal project running.

[sgnAudio]

wow, thank you. This are great news. Excellent support here. I am a bit busy with the hardware now, but soon I will move to the software side.