This change extend the CMake files with the necessary additions to build for z/OS.
Is it actually true that the resulting code is not position-independent? I thought that all XPLINK code is DLL-enabled. The outcome where the resulting code is position-independent (without the need to specify additional options) should be expressed differently from what is done here.
The various "strip" binder options are not the default, so there is a TODO here to enable the removal of the unneeded portions of the input to the linking process (which should help in terms of binary size).
I think CMAKE_SYSTEM_NAME (used above for z/OS) is right: The "host" of the resulting build is the target of this CMake build. @daltenty, if you agree, I think a small patch would make sense (likely to create a merge conflict with this one though)...
What is the nature of this limitation? "Not supported" messages tend to confuse, because someone wanting to solve the issue (other than not using whatever is "unsupported") needs some rationale in order to make progress.
Indeed, the text of the message speaks to a limitation to the implementation strategy used by the build and does not directly say much about there being a limitation in achieving the outcome that the option is intended to produce.
I agree that is probably more desirable in the long run, though it does create a behavior difference between platforms which rely on "config.guess" (which won't respect the CMAKE_SYSTEM_NAME and will always use the host) and those that don't (i.e. AIX / z/OS).
I am suggesting that we use CMAKE_SYSTEM_NAME for both the AIX and z/OS queries (i.e., we should be consistent between the two here). The CMAKE_HOST_SYSTEM_NAME does not always reflect the host system for a build using the compiler resulting from the current build.
@daltenty pointed out that there is a logic error for some other platforms (and that using CMAKE_HOST_SYSTEM_NAME is consistent with that logic error). I do not believe that adopting the logic error for AIX and z/OS is necessarily better.