Building WASM modules for H7 radios (e.g. TX16sMK3, TX15) under Windows fails

[mha1]

Problem:
Using current main wasm builds fail while generating datacopy.inc with error radio/src/gui/colorlcd/mainview\datastructs_screen.h:200:42: error: use of undeclared identifier 'LCD_W'

Analysis:
radio/src/gui/colorlcd/mainview/datastructs_screen.h requires LCD_W which is defined in hal_settings.h which will be built only after datacopy.inc is generated using the Windows build environment. Generating datacopy.inc depends on target hal_settings. The build sequence might be dependent on the host build environement and maybe working accidentally in other environments.

Solution:
Add hal_settings dependency to function(GenerateDatacopy source output) in radio\src\CMakeLists.txt

Tests:
Tested ok for TX15, TX16sMK3 and TX16s wasm module build

[philmoz]

The 'datacopy.inc' file is not needed at all when building for the simulator so probably better to just exclude it completely.

[pfeerick]

datacopy.inc is only needed to inform radios that have RTC backup memory what settings to shove into the RTC backup RAM - thus of no use to simulator.

The underling issue is probably more an ordering issue coming from parallelism, and/or how ninja behaves since you're probably using that on windows. Without the actual commands you are running it's hard to tell if something there is what triggered this.

We can't just exclude the datacopy.inc generation when building for simulator/native, as that will break the unit tests that test the rambackupWrite and restore behaviour... but we should be able exclude it for WASI... but if we fix the dependency generation order, it is also somewhat pointless.

Can you see if this works for you? The first pins the dependency order racing, and the second skips for WASM builds, so simu and native builds/tests should be unaffected.

diff --git a/cmake/Macros.cmake b/cmake/Macros.cmake
index 2e781b93fe..6f6d2978e6 100644
--- a/cmake/Macros.cmake
+++ b/cmake/Macros.cmake
@@ -62,7 +62,9 @@ endfunction()
 function(GenerateDatacopy source output)
 
   set(GEN_DATACOPY ${RADIO_DIRECTORY}/util/generate_datacopy.py)
-  set(GEN_DATACOPY_DEPEND ${CMAKE_CURRENT_SOURCE_DIR}/${source} ${GEN_DATACOPY})
+  set(GEN_DATACOPY_DEPEND
+    ${CMAKE_CURRENT_SOURCE_DIR}/${source} ${GEN_DATACOPY}
+    ${CMAKE_CURRENT_BINARY_DIR}/hal_settings.h)
 
   # Fetch defines / include directories in use
   AddCompilerFlags(GEN_DATACOPY_ARGS)
diff --git a/radio/src/CMakeLists.txt b/radio/src/CMakeLists.txt
index f12cb998a3..94c1c5ea13 100644
--- a/radio/src/CMakeLists.txt
+++ b/radio/src/CMakeLists.txt
@@ -225,7 +225,7 @@ if(STORAGE_MODELSLIST)
   add_definitions(-DSTORAGE_MODELSLIST)
 endif()
 
-if(RTC_BACKUP_RAM)
+if(RTC_BACKUP_RAM AND NOT WASI)
   add_definitions(-DRTC_BACKUP_RAM)
 
   GenerateDataCopy(datastructs_private.h datacopy.inc)

[mha1]

We can't just exclude the datacopy.inc generation when building for simulator/native, as that will break the unit tests that test the rambackupWrite and restore behaviour... but we should be able exclude it for WASI... but if we fix the dependency generation order, it is also somewhat pointless.

Yes, I came to the same conclusion and it's really just a ordering issue with duck hal_settings.h not being in the row . Your change also works. Sold, thank you very much.