chore: Update MSYS2 Windows 32 and 64 bit toolchain and build scripts

[elecpower]

Summary of changes:

• based on previous MSYS2 64-bit scripts
• environment aware MSYS2 Win 32 and 64-bit toolchain and compile scripts
• amendments for changes to MSYS2 package contents, Qt 5.15.2, support tools and make things work
• add cli options and parameters
• support v2.10 change using hwdefs
• use repo supported radio types and libsims rather than independent lists hardcoded in the scripts

Todo:

• update documentation (after testing and approval)

[offer-shmuely]

tried to make my environment buildable again
the msys2_setup_buildenv_stage1_32_64.sh succeded
the msys2_setup_buildenv_stage2_32_64.sh does not pass the
read -p "Press any key to continue or ctrl+C to abort"

I comment out the "read -p ..."

next failure is

[elecpower]

Usually not running the latest version of aqt as this is a newer option. The new build script does not specify a version.

[mha1]

@offer-shmuely If you haven't done so: the new install scripts will not work on an existing MSYS2 installation. You need to deinstall MSYS2 entirely an re-install MSYS2 using the new install guide and scripts.

[offer-shmuely]

Not familiar with MSYS
Where is the “new install guide”?

[mha1]

oops, idk if Neil already update the how-to. but it's similar to the current one. deinstall MSYS2 and try the new scripts

[pfeerick]

Is this ready to go or was more work needed?

[rotorman]

only Enter works, thus "Press Enter key to continue or Ctrl+C to abort".

[rotorman]

IMHO better, than setting an operating system wide setting for EdgeTX, would be to explicitly use -DARM_TOOLCHAIN_DIR in EdgeTX CMake line, e.g. here then with ARM GNU 11.3.1 -DARM_TOOLCHAIN_DIR="C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin".

Setting something system wide might affect users building other (non EdgeTX) code on their systems.

[elecpower]

Apparently this does not work anyway as there are spaces in the path.
Let's just say there was robust discussion when I posted these new scripts about how best to pass the ARM path.
I too prefer the -D method.

[rotorman]

Tested this PR under Win11 Pro 23H2 64-bit. With the comments and changes I posted above and below this post, all worked (was able to build radio firmware, Companion, Simulator binary and library and create an installer executable).

This PR should remove tools/setup_buildenv_msys2_stage1.sh and tools/setup_buildenv_msys2_stage2.sh (as it is replacing the scripts with 4 new files named differently).

After my comments are worked in, I see no issue merging this PR into main. I would also update the Wiki page https://github.com/EdgeTX/edgetx/wiki/Build-Instructions-under-Windows-10-%28MSYS2%29 accordingly, e.g. to also update the CMAKE_PREFIX_PATH to $HOME/qt/5.15.2/mingw81_64.

For someone wanting to test, here the full working CMake line for RM Zorro:

 cmake -G "MSYS Makefiles" -Wno-dev -DCMAKE_PREFIX_PATH=$HOME/qt/5.15.2/mingw81_64 -DSDL2_LIBRARY_PATH=/mingw64/bin/ -DPCB=X7 -DPCBREV=ZORRO -DDEFAULT_MODE=2 -DLUA_MIXER=YES -DARM_TOOLCHAIN_DIR="C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin" -DCMAKE_BUILD_TYPE=Release ../

[elecpower]

This PR was built well before the infamous ADC refactor was released (which keeps on giving). Also Peter has needed to do some tricks to keep the compilations working with updates to the MSYS packages. So it does need revisiting.
I'll put it to the test again and take onboard your latest feedback. Once we are okay with the result its time to do some updated documentation.

[elecpower]

The ADC refactor broke Companion compile as the hw def json files are not where CMake expects. Companion compiles, it just does not have any definitions to load for the radio profiles. So a fix required.

[pfeerick]

Really need to make the json generation recursive (i.e. a bit like what tools/generate_hw_defs.sh or tools/generate_yaml.sh does) so that it can be it's own build step, rather than depending on calling libsimulator builds for all desired radios you want the companion build to support. Maybe something like the AddHardwareDefTarget macro could work?

[elecpower]

That's the direction I am going. I take that approach in my Linux dev environment.

[elecpower]

@pfeerick @rotorman okay so the scripts are working but I need to do more use cases tests before recommending merging.
The hardware definitions generation is painfully slow due to resetting the cmake environment for each radio so any thoughts would be most welcome.
Feel free to give them a spin and let me know of any issues/suggestions.

[markomajic]

Were there any changes/updates to this since May? I wanted to setup a Windows dev environment to play around a bit with EdgeTX code and it's been a struggle. I tried on two different Windows 11 (both 23H2) with what's currently available for download from www.msys2.org (msys2-x86_64-20240727) without success... On the first machine, there were some random errors/warnings during "stage 2" script - but it was able to compile firmware but not companion, libsimulator or simulator (all targets reported as not present in the Makefile). On the second machine things looked better (but turned out worse) as I didn't notice and errors or warnings during "stage 2" but... All targets (including firmware) were missing from the Makefile (I did run 'make configure')... Just checking if there are updated "recipes" out there?

I was able to deploy a working dev environment by following https://github.com/EdgeTX/edgetx/wiki/Build-Instructions-under-Ubuntu-20.04 "recipe" (but only when I switched to 22.04 from 20.04!?) and, I should say, with VS.Code's "remote connection" feature directly into WSL's VM (and built in graphics support) - it's really a nice and comfy dev environment and a refreshing departure for a lifelong C/C++ guy coddled by IDE-hand-holding - takes me back to the university days (and that's going some ways back lol)... But I'd really prefer to build Windows binaries (it just seems easier seeing as I have all Windows machines) so I've been banging my head against the wall for the past few days... Thx!!

[elecpower]

Since v2.10 you do need to compile the libsimulator before Companion and Simulator.

[markomajic]

Thanks for the reply... I am not able to build libsimulator either - it seems that none of the targets are generated in the makefile (I get the message "*** No rule to make target 'libsimulator'. Stop."...

It seems that Qt either wasn't (fully) installed or was installed but somewhere were the CMake cannot find it...

But... I suppose this probably isn't the right forum for these kinds of questions (and cries for help ;-)) - my apologies...

[elecpower]

Now supports v2.10 hwdefs and uses repo supported radios and libsims

[elecpower]

@pfeerick I have finished my testing and tinkering so now just bug fixes anyone else finds

[pfeerick]

Just ran this on a squeaky new install of MSYS2... Stage 1 ran perfectly. Stage 2 has hit a snag with the python 3.11+ "externally managed environment" changes...

i.e.

=== [INFO] Step 4: Installing Python setuptools and wheel
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try 'pacman -S
    $MINGW_PACKAGE_PREFIX-python-xyz', where xyz is the package you
    are trying to install.

Adding --break-system-packages to the pip install command to restore behaviour of prior versions seems acceptable in this instance since this is supposed to be a dedicated/self-contained setup?

This unfortunately only seems to work until you hit the aqtinstall stage... then the distutils depreciation (or something else) completely borks this again... perhaps it is better to download and use the self-contained aqt executable from https://github.com/miurahr/aqtinstall/releases (referenced from https://pypi.org/project/aqtinstall) ? I manually downloaded it, and changed the calls to reference it rather than the python package version, and it worked just fine... after export SETUPTOOLS_USE_DISTUTILS=stdlib was removed as that sets off multiple warning messages about distutils being depreciated.

How is msys2_build intended to be used? As I'm hitting "unsupported radio simulator" when I try something like ./msys2_build.sh -f boxer from the tools subdirectory...