machine.subsystem() defaults to the same as machine.system(), but should it?

[smcv]

As discussed in https://github.com/mesonbuild/meson/pull/13722#pullrequestreview-2334146197, there are no subsystems documented for OSs other than the Darwin family.

mesonbuild.environment makes subsystem default to the same thing as system on other OSs, but is this really a useful default? Would it be better for subsystem to be empty/unset on platforms where nobody has yet decided what to put there?

Similarly, meson env2mfile for dpkg-based systems currently populates subsystem with the same thing as system.

On Linux, subsystem might be a reasonable place to distinguish between different libc implementations (glibc, musl, uclibc, etc.), or possibly between ABIs (32-bit ARM OABI and EABI, or mips O32/N32/N64 ABIs), but it can't be used for either of those if people start relying on it taking values like linux.

[smcv]

cc @dcbaker

related: #13739

[dcbaker]

My preference would be for .subsystem() to return 'macos' on Apple (since no other darwin derivative can be used as a build machine AFAICT), and probably not implement it otherwise, ie, return an empty string.

It would be nice if we could start figuring out how to describe non Apple products, particularly the differences between GNU/Linux, Android/Linux (and possibly non-GNU Linux? Maybe just call it POSIX/Linux?, unsure), and Debian/kFreeBSD and FreeBSD (ie, GNU/FreeBSD and FreeBSD/FreeBSD).

[smcv]

My preference would be for .subsystem() to return 'macos' on Apple (since no other darwin derivative can be used as a build machine AFAICT)

I believe this is already true.

and probably not implement it otherwise, ie, return an empty string

The essence of this issue report is that this is not true: subsystem is currently the same as system on all non-Darwin.

It would be nice if we could start figuring out how to describe non Apple products, particularly the differences between GNU/Linux, Android/Linux (and possibly non-GNU Linux? Maybe just call it POSIX/Linux?, unsure), and Debian/kFreeBSD and FreeBSD (ie, GNU/FreeBSD and FreeBSD/FreeBSD).

The current state is that GNU/Linux is system() -> 'linux' (documented), Android/Linux is system() -> 'android' (documented), and I think Linux systems based on other user-spaces (musl, uclibc, klibc, etc.) are also system() -> 'linux' (undocumented).

I think kernel() -> 'linux', system() -> 'linux', subsystem() -> 'gnu' would make sense for GNU/Linux, with the other user-space environments on Linux treated as distinct subsystems, and system() special-cased to be android on Android and linux otherwise? That seems comparable to the difference between Apple's environments.

Another question for Linux is whether non-default ABIs should be reflected in the subsystem. In GNU naming, most Linux architectures are *-linux-gnu, but ARM EABI is *-linux-gnueabi or *-linux-gnueabihf, and the mips family also has several ABIs. Perhaps gnueabi, gnueabihf, etc. would make sense as subsystems in Meson naming?

Ordinary FreeBSD is definitely kernel() -> 'freebsd', system() -> 'freebsd', and would currently also be subsystem() -> 'freebsd'.

GNU/kFreeBSD was recently removed from the Debian Ports autobuilder infrastructure and no longer has a porter-accessible machine, so it probably isn't coming back any time soon, and therefore probably isn't worth spending much time on. It also isn't straightforward to read old build logs and find out how Meson reported itself, because they've disappeared from the autobuilders' web interface. I think if someone resurrects the port, they get to decide what it returns for kernel() (presumably ought to be freebsd), system() (env2mfile thinks this is kfreebsd, but I don't have a kFreeBSD system and I don't know whether that reflects reality on native builds), and subsystem(), and send PRs if required.