[Pkg-cmake-team] Bug#930995: cmake: please document how Debian architectures map to CMake's taxonomy of operating systems and CPU architectures

Simon McVittie smcv at debian.org
Mon Jun 24 11:24:23 BST 2019


Package: cmake
Version: 3.13.4-1
Severity: wishlist

CMake's upstream documentation says:

    CMAKE_SYSTEM_PROCESSOR

    The name of the CPU CMake is building for.

    This variable is the same as CMAKE_HOST_SYSTEM_PROCESSOR if you build
    for the host system instead of the target system when cross compiling.

and:

    CMAKE_HOST_SYSTEM_PROCESSOR

    The name of the CPU CMake is running on.

    On systems that support uname, this variable is set to the output
    of uname -p, on windows it is set to the value of the environment
    variable PROCESSOR_ARCHITECTURE.

(On Linux, this is actually incorrect: uname -p replies "unknown", and
by experiment it appears that CMake is actually using uname -m.)

This doesn't answer questions like: if I need to special-case powerpcspe
systems for some reason, what CMAKE_HOST_SYSTEM_PROCESSOR should I be
looking for?

Similarly, CMake upstream does document that CMAKE_[HOST_]SYSTEM_NAME is
"Linux" when compiling on/for Linux systems, but I haven't been able to
find any documentation of what it should be on GNU/kFreeBSD or GNU/Hurd.

It would be helpful if there was a human- and machine-readable
table similar to dpkg's /usr/share/dpkg/*table that mapped
each dpkg architecture (or at least the Debian release and -ports
architectures) to a canonical value of CMAKE_[HOST_]SYSTEM_PROCESSOR and
CMAKE_[HOST_]SYSTEM_NAME. That way, tools like debhelper dh_auto_configure
wouldn't have to guess.

Unfortunately, the design chosen by CMake upstream (delegating the
taxonomy of CPU names to uname -p/uname -m/Windows PROCESSOR_ARCHITECTURE)
means that the same CPU will in general have different names on
different OSs, so it will not be possible to build a table like
https://mesonbuild.com/Reference-tables.html#cpu-families that remains
true across all operating systems.

    smcv



More information about the Pkg-cmake-team mailing list