These two lines doesn't appear to be needed if cmake_minimum_required is 3.28?

Hi.

In cmake, most policies default to the OLD behaviour, in order to remain compatible to previous behaviour when people bump up cmake_mininum_required_version.

CMP0048's last paragraph states that unless explicitly set, the old behaviour will be used.
The same goes for CMP0091.

No?

CMP0091 page

Use the cmake_policy() command to set it to OLD or NEW explicitly.

The cmake_minimum_required page from v3.28 says

All policies known to the running version of CMake and introduced in the (or , if specified) version or earlier will be set to use NEW behavior.

I think this means cmake_minimum_required(VERSION 3.28) will set NEW for all the policies introduced in VERSION <= 3.28.

I don't have access to Windows machine now, but last time I checked, for relative newer CMake, this is useless. However, I am not sure at all.

It was not required for older versions of cmake, i.e. before 3.15.
Starting with 3.15, CMP0091 deprecated the automatic setup of the correct runtime library.

If CMP0091 isn't set at the prelude section, the explicit setting of MSVC_RUNTIME_LIBRARY is not required. In my opinion, the old behaviour was "friendlier", as this line is more or less a triviality, but now needs to be written all over the place. The OLD behaviour, however, is deprecated.

No opinion about this line, this means if the compiler by default uses 20 or 23 then the code will be compiled in 20 or 23 mode.

Alternatively, set the version to fixed 17

set_property(TARGET tkrzw PROPERTY CXX_STANDARD 17)

I agree with CXX_STANDARD being more readable.

However, it is ancient. and was/is meant as a relieve from the days people were writing hundreds of lines of cmake code to add the compiler specific option for -std=c++11 (which might require to be denoted as -std=c++0x). Because all those self-written cxx_standard code had tweaks and fallbacks and odd hacks, CXX_STANDARD doesn't actually enforce anything unless CXX_STANDARD_REQUIRED is also set. And then, CXX_EXTENSIONS has to be disabled, as the default to CXX_STANDARD would enable vendor specific extentions, which isn't what the autoconf code was doing.

All three options, unlike cxx_std_XX, can be set globaly, with something like

set (CMAKE_CXX_STANDARD 14)
set (CMAKE_CXX_EXTENSIONS OFF)
set (CXX_STANDARD_REQUIRED ON)

so the fact it's 3 options to set would be a minor issue for large projects with many targets.

However, CXX_STANDARD does not trancend, which is a showstopper: Inside of the tkrzw build, setting up c++17 mode, either globaly or by a lot of set_property calls, might be good enough to build tkrzw.

When the built targets gets installed, however, this configure_package_config_file call generates a file that is then installed, containing everything other projects require in order to use the tkrzw targets, similar to the pkg-config file that is generated by autotools.
The other project doesn't know anything about global variable setups in tkrzw, and as CXX_STANDARD doesn't transcend, "using" tkrzw will not imply the requirement for a c++17 mode to the consuming project. cxx_std_XX does transcends to all consumers, up- but not down-grading the c++ standard in use, i.e. if a consumer uses c++11 itself but links against tkrzw, it will be upgraded to use c++17, while a project using c++23 will keep using 23 despite linking against tkrzw.

I'm currently working on this integration.