[fix] CMake linker failure on ARM when DNN is disabled and NEON uses RTCD

[uilianries]

Greetings!

As the Opus project is packaged in Conan Center already, and the newest version 1.6.1 is available, we are packaging 1.6.1 as well on PR conan-io/conan-center-index#30332.

However, during the build, was noted a regression regarding Windows ARM build:

[148/148] Linking C shared library opus.dll
FAILED: opus.dll opus.lib 
C:\Windows\system32\cmd.exe /C "cd . && C:\j\30332-1\cmake7ff18b9498382\p\bin\cmake.exe -E vs_link_dll --msvc-ver=1944 --intdir=CMakeFiles\opus.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~2\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\bin\Hostx64\arm64\link.exe /nologo @CMakeFiles\opus.rsp  /out:opus.dll /implib:opus.lib /pdb:opus.pdb /dll /version:0.11 /machine:ARM64 /INCREMENTAL:NO && cd ."
LINK: command "C:\PROGRA~1\MICROS~2\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\bin\Hostx64\arm64\link.exe /nologo @CMakeFiles\opus.rsp /out:opus.dll /implib:opus.lib /pdb:opus.pdb /dll /version:0.11 /machine:ARM64 /INCREMENTAL:NO /MANIFEST:EMBED,ID=2" failed (exit code 1120) with the following output:
   Creating library opus.lib and object opus.exp

arm_dnn_map.c.obj : error LNK2001: unresolved external symbol compute_activation_c
arm_dnn_map.c.obj : error LNK2001: unresolved external symbol compute_conv2d_c
arm_dnn_map.c.obj : error LNK2001: unresolved external symbol compute_activation_neon
arm_dnn_map.c.obj : error LNK2001: unresolved external symbol compute_conv2d_neon
opus.dll : fatal error LNK1120: 4 unresolved externals

The full build log can be found here: https://c3i.jfrog.io/artifactory/cci-build-logs/cci/prod/PR-30332/1/package_build_logs/build_log_opus_1_6_1_3e860e0cda08f385295e313be24b0569_4432a0a14d3f85a3674742d1be4261502c686dae.txt

Previously, on version 1.5.2, we could build Opus for Windows ARM without errors: https://c3i.jfrog.io/artifactory/cci-build-logs/cci/prod/PR-28391/1/package_build_logs/build_log_opus_1_5_2_18fcc73dcd16edae063173f3ceb3ed56_4432a0a14d3f85a3674742d1be4261502c686dae.success.txt.

---

When comparing version 1.5.2 and 1.6.1 (v1.5.2...v1.6.1), it's possible to note a few changes regarding ARM, including the commit aa0e5a0.

When building for an ARM target with NEON detected at runtime (RTCD path, e.g. OPUS_MAY_HAVE_NEON is true and OPUS_ARM_PRESUME_NEON is false), the CMakeLists.txt unconditionally adds dnn/arm/arm_dnn_map.c to the build regardless of whether the DNN subsystem (OPUS_DNN) is enabled. This is the cause of the observed link failure.

This PR brings a change in the CMakeLists.txt, by wrapping dnn_sources_arm_rtcd in if(OPUS_DNN) so arm_dnn_map.c is only compiled when the symbols it references are actually present. Same for dnn_sources_arm_neon, so affecting nnet_neon.c.
Later, the if(OPUS_DNN AND NOT OPUS_MAY_HAVE_NEON) prevents nnet_neon.c from being added twice when both OPUS_DNN and OPUS_MAY_HAVE_NEON are true.

To prove this log is working, I executed an internal build with this change, with Opus 1.6.1:

• Windows ARM + Opus 1.6.1 + Static library: opus-1.6.1-windows-arm-msvc194-release-static.log
• Windows ARM + Opus 1.6.1 + Shared library:opus-1.6.1-windows-arm-msvc194-release-shared.log

Environment

The CI environment is configured as follows:

Opus version: 1.6.1
Build system: CMake (Ninja generator)
Host: Windows x86_64 (cross-compiling)
Compiler: MSVC 194
Target: Windows ARM64
Options: shared=True, fixed_point=False — DNN features (OPUS_DEEP_PLC, OPUS_DRED, OPUS_OSCE) are all OFF (defaults)

Feel free to ask for any extra information about the case. Regards!