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

Hi Simon!
The Debian Wiki has a table that maps Debian architectures to uname -m
outputs: https://wiki.debian.org/ArchitectureSpecificsMemo

I added a few missing entries by grepping the kernel 5.14 sources
as it is described here: https://stackoverflow.com/a/45125525/13476707

Is this the data that should go into the (arch-)table?


Cheers
Timo

I know, I added that table in an attempt to provide some of the information
that maintainers need!
missing information in that table than inaccurate information. If you're
unsure, trying it on a porterbox or asking porters is probably better than
adding information that might be wrong.

    smcv

I know, I added that table in an attempt to provide some of the information
that maintainers need!
missing information in that table than inaccurate information. If you're
unsure, trying it on a porterbox or asking porters is probably better than
adding information that might be wrong.

    smcv

* Simon McVittie <smcv@debian.org> [2021-10-25 11:31]:
The whole Wiki page is a treasure trove of information and one of my
favorite Debian bookmarks, so thank you for your part in it!
The only thing where I was unsure was the MIPS architecture, where I
could not confirm which compat name is used when, so I followed the
lead of the ARM architecture and added "mips*" for the common prefix that
all identifiers share. I hope that's okay.

My gut feeling says there won't be much activity on this from other
people, so now is as good a time as any to come up with a useful
table, even if it is incomplete. What do you think?


Cheers
Timo

Hi,

* Niels Thykier <niels@thykier.net> [2025-08-24 09:50]:

There is an open wishlist bug [1] about properly mapping Debian
architectures to CMake systems and processors.

A possible alternative would be the CMAKE_LIBRARY_ARCHITECTURE variable,
which is initialized during compiler configuration for C, CXX, and
Fortran and has the same value as DEB_HOST_MULTIARCH. Any
architecture-specific setup in upstream code could be patched to check
that variable instead of CMAKE_SYSTEM_PROCESSOR.


Cheers
Timo

[1] https://bugs.debian.org/930995