Fix win11 arm64

[gzotti]

Description

This shall include fixes identified during testing work on Arm64 hardware donated by Microsoft.

Apart from the tests listed in #4772, getting ASCOM to play nice seems the largest issue. :-(

Fixes #4772 (issue)

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• Housekeeping

How Has This Been Tested?

Test Configuration:

• Operating system: Windows 11 on ARM64 25H2
• Graphics Card: Qualcomm Adreno X1-85

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

Files matching guide/**:

• Did you remember to update screenshots to match new updates?
• Did you remember to grammar check in changed part of documentation?

This is an automatically generated QA checklist based on modified files.

[gzotti]

With some help from the ASCOM developers we found that we need a sidecar file stellarium.exe.config to be installed next to stellarium.exe:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
    <supportedRuntime version="v2.0.50727"/>
  </startup>
</configuration>

Where should this go in the repo (inside ASCOM sources?), and how do I ensure it is being copied to the install folder? In addition, apparently this use of ASCOM based on .NET requires a signed program to run without interference of 'Smart App Control'.

I am in the process of upgrading qDebug() etc into qCDebug(Telescopes) and decide what's debug and what's a warning, but this should go into all parts of the plugin, will take a few days longer. We can then finetune also this plugin, with qCWarning as default.

[alex-w]

@gzotti it’s an easy - please see similar files in data directory + iss files in cmake directory (of course if you want to put this file when telescope control plugin is enabled then you need to update CMakeLists.txt file too)

[gzotti]

Now I am back at the coding style issue. Using the .clang-format, indentation works with tabs. When I store the file, tabs are replaced by 8 spaces. Where is the switch to fix that nonsense?

EDIT: Bah, found it. Preferences/Text Editor/Cleanups Upon Saving. Disable "Clean indentation".

[alex-w]

Thanks. But IMHO it should be behind "if ENABLE_PLUGIN TelescopeControl and ASCOM" (or something similar that works :-).

Yes, we can do it, but I'm not sure that we need overengineering here...

[alex-w]

OK, could you prepare the branch to merge?

[gzotti]

Yes, will do tonight.

[gzotti]

I squashed a few commits where mostly typos and early build failures were involved. Should I squash the numerous appveyor-and-cmakefile-only commits into just one?

[alex-w]

I squashed a few commits where mostly typos and early build failures were involved. Should I squash the numerous appveyor-and-cmakefile-only commits into just one?

At next step you want to use squash or rebase?

[gzotti]

I think we should rebase-merge the branch to keep the few interesting "content" commits (changes for Arm integration, ASCOM stuff, windows screen scaling change) separate. Of course, some more of the 18 last commits (appveyor and CMakeFiles only) commits can still be squashed before merge when the result of an experimental change in the CI settings was just a failed CI run. In the end I would keep most comments in the appveyor file for reference when continuing raising Qt version for the arm build after the 26.1 release. When Arm builds on Qt6.10 I will be more than happy to remove the now-commented out "poke the CI for info what's happening" parts.

What about the two windeployqt runs in src/CMakeLists.txt? Should they have the same arguments?

[alex-w]

What about the two windeployqt runs in src/CMakeLists.txt? Should they have the same arguments?

this is two different cases for windeployqt ;)

[gzotti]

I can see that. GENERATE_STELMAINLIB=false for MSVC, so the second call is almost never executed (only when doing private builds on MSYS? But never on appveyor/MSVC configs), and therefore maybe some arguments have not been added/updated in the last few years. Still, is it useful to add qt_paths, or set verbosity level?

[alex-w]

Still, is it useful to add qt_paths, or set verbosity level?

Yes, of course it’s useful - in any way (MSVC or MinGW/MSYS) windeployqt is called for packaging (MinGW/arm64 is working too)

[gzotti]

What's the problem in the Mac/Qt5 build now?

[alex-w]

What's the problem in the Mac/Qt5 build now?

Troubles in qt5 package, please ignore it at the moment

[gzotti]

OK. Should we do one final test before merge? Else it's ready IMO.

[alex-w]

It's ready to merge IMHO

[github-actions]

Hello @gzotti!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @gzotti!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest