Specify target platform version in binary artifacts

[y-guyon]

No description provided.

[y-guyon]

Versions were arbitrarily selected in https://en.wikipedia.org/wiki/Microsoft_Windows_SDK and https://en.wikipedia.org/wiki/MacOS_version_history.

[wantehchang]

Yannis: Thanks a lot for writing this pull request. I asked James to review this.

I suggest we follow this OS support table: https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md

[y-guyon]

I do not fully grasp the implications of passing this flag or not and using a newer or older version.

Could you describe what could go wrong in these scenarios:

• Binary compiled with CMAKE_OSX_DEPLOYMENT_TARGET=X and run on platform version < X (the OS just refuses to run that binary, right?)
• Binary compiled with CMAKE_OSX_DEPLOYMENT_TARGET=X and run on platform version >= X (all is fine)
• Binary compiled without CMAKE_OSX_DEPLOYMENT_TARGET (I guess CMake assigns some value X depending on the environment at compile time and this scenario is equivalent to the two others)

I understood that setting a target version makes sure no system call introduced in a later platform version is used. If that is the only impact, why not use the oldest possible target version?
From what I saw, setting CMAKE_OSX_DEPLOYMENT_TARGET does not change the SDK version used to compile libavif anyway.

Same questions as above for CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION instead of CMAKE_OSX_DEPLOYMENT_TARGET if the behavior is different on Windows.

---

Should we use CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION, CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION, or both?

[jzern]

I do not fully grasp the implications of passing this flag or not and using a newer or older version.

Could you describe what could go wrong in these scenarios:

• Binary compiled with CMAKE_OSX_DEPLOYMENT_TARGET=X and run on platform version < X (the OS just refuses to run that binary, right?)

This sets -mmacosx-min-version / -mmacos-min-version, so in general that would be my expectation, unless no new functions were used and you got lucky in the shared object dependencies.

• Binary compiled with CMAKE_OSX_DEPLOYMENT_TARGET=X and run on platform version >= X (all is fine)
• Binary compiled without CMAKE_OSX_DEPLOYMENT_TARGET (I guess CMake assigns some value X depending on the environment at compile time and this scenario is equivalent to the two others)

I understood that setting a target version makes sure no system call introduced in a later platform version is used. If that is the only impact, why not use the oldest possible target version?

Security / bug fixes in the library functions would be the main reason. But if the goal is to support back to some version it's what you're left with.

From what I saw, setting CMAKE_OSX_DEPLOYMENT_TARGET does not change the SDK version used to compile libavif anyway.

https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html. So for the most part just -mmacos-version-min will be set. It sounds like in cases where multiple versions of the SDK were installed this might also influence that.

Same questions as above for CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION instead of CMAKE_OSX_DEPLOYMENT_TARGET if the behavior is different on Windows.

Should we use CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION, CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION, or both?

It sounds like CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION won't be used for non-WindowsStore projects:

https://cmake.org/cmake/help/latest/prop_tgt/VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION.html#prop_tgt:VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION

CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION will choose a SDK version. I guess if you wanted to support the oldest versions of Windows 10, you could specify it, but I feel like this might be something to address if there's a compatibility issue reported by a user.

[y-guyon]

It sounds like CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION won't be used for non-WindowsStore projects:

https://cmake.org/cmake/help/latest/prop_tgt/VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION.html#prop_tgt:VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION

It is unclear to me if "the target platform minimum version will not be specified for the project" when:

• VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION is not specified, or
• it is not a WindowsStore project.

CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION will choose a SDK version. I guess if you wanted to support the oldest versions of Windows 10, you could specify it, but I feel like this might be something to address if there's a compatibility issue reported by a user.

It is unclear to me what "might be something to address if there's a compatibility issue reported by a user".
Should we NOT use CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION until a user complains, or should we DO use CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION set to a recent version and downgrade it once a user needs it?

[jzern]

It is unclear to me what "might be something to address if there's a compatibility issue reported by a user".
Should we NOT use CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION until a user complains, or should we DO use CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION set to a recent version and downgrade it once a user needs it?

I was thinking we would leave things as is and wait for a report about incompatibility. That might be a little fragile if we move the builder to Windows 11. We can try what you have and see if there are any issues.

[jzern]

Actually I wonder if CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION only affects the Visual Studio generator; NInja is being used now.

Actually I wonder if CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION only affects the Visual Studio generator; NInja is being used now.

https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html

When targeting Windows 10 and above, Visual Studio Generators for VS 2015 and above support specification of a Windows SDK version:

[jzern]

With -G Ninja:

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION

[y-guyon]

Are you suggesting dropping -G Ninja in general?
I myself often favor omitting the generator selection argument and use cmake --build instead of make or ninja.
Do you know why we select ninja instead of letting CMake pick something?

[jzern]

Are you suggesting dropping -G Ninja in general? I myself often favor omitting the generator selection argument and use cmake --build instead of make or ninja. Do you know why we select ninja instead of letting CMake pick something?

If we want to go forward with the Visual Studio variables we will need to use the Visual Studio project generator. I'm guessing ninja was used because locally it will be faster since it will parallelize on the file level, not project. For something like there's less of a need for it.