[depends] bump libjpeg-turbo to 2.0.4

[Rechi]

How Has This Been Tested?

compiled libjpeg-turbo and it's dependencies for Android (aarch64, arm, i686), iOS (aarch64, arm), macOS and tvOS

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[AlwinEsch]

This in case of Raspberry not correct enough, there it is only "arm" without something else, also on Android 32bit it is only "arm".

EDIT: On libjpeg-turbo it checks only about "arm*" and it works, but not sure if on all possible depends (specially by addons) correct.

[AlwinEsch]

See about Android here the standardized values of them https://github.com/Kitware/CMake/blob/master/Modules/Platform/Android-Determine.cmake#L243-L252 (on ..._PROC)

[AlwinEsch]

I'm torn, which would be better 😄, if you go here it is fully OK https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html.

Now looked over hundreds of CMakeLists.txt on the web, with the set(CMAKE_SYSTEM_PROCESSOR ...) many use it completely (e.g. armv7l), but in the comparison I saw everywhere only for "arm" alone.

• The most make a if (CMAKE_SYSTEM_PROCESSOR MATCHES "^arm")
• Some are stupid and make a if(CMAKE_SYSTEM_PROCESSOR STREQUAL "arm"
• Some half stupid and make a if(CMAKE_SYSTEM_PROCESSOR STREQUAL "arm" OR CMAKE_SYSTEM_PROCESSOR STREQUAL "armv7l")

Then this path is actually OK, just a shame because of my work 😢 😆 😎.

[fuzzard]

for the DCMAKE_ASM_NASM_COMPILER is it worth using the existing NASM var?

xbmc/tools/depends/native/config.site.native.in

Line 26 in 353d610

NASM=@prefix@/@tool_dir@/bin/yasm

also, purely for reference if anyone looks in the future, libjpeg-turbo build docs say it can use either yasm or nasm, with some caveats around macos nasm min version apparently

If using NASM, 2.10 or later is required.
If using NASM, 2.10 or later (except 2.11.08) is required for an x86-64 Mac build (2.11.08 does not work properly with libjpeg-turbo's x86-64 SIMD code when building macho64 objects.)
If using YASM, 1.2.0 or later is required.
If building on macOS, NASM or YASM can be obtained from MacPorts or Homebrew.
NOTE: Currently, if it is desirable to hide the SIMD function symbols in Mac executables or shared libraries that statically link with libjpeg-turbo, then NASM 2.14 or later or YASM must be used when building libjpeg-turbo.

https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/BUILDING.md