cps

cps copied to clipboard

The specification has attributes Kernel and Kernel-Version. For Kernel, the specification says

Specifies the name of the operating system kernel required by the package’s components. The value is case insensitive and should follow the output of uname -s. Typical values include "windows", "cygwin", "linux" and "darwin".

The Single UNIX Specification says that the -s flag to uname causes it to "Write the name of the implementation of the operating system.", saying nothing about the kernel.

Linux is the only OS that draws such a strong distinction between the kernel and the OS as a whole; the kernel of Darwin, for example, is called XNU, but uname -s on a Darwin-based system prints "Darwin", not "XNU".

And even the value reported by uname -s doesn't necessarily fully describe the platform on which you're running; macOS, iOS, watchOS, and tvOS all use Darwin as the "core operating system", but something that can be used on macOS might not be usable on iOS, for example.

For Linux, you'd have "GNU/Linux", i.e. Linux plus something based on GNU libc, and "Bionic/Linux", better known as "Android", and so on.

Even if Kernel were replaced by, for example, OS in the names, to indicate the full OS rather than just the OS kernel, a UN*X-only package running on multiple UN*Xes wouldn't have a single OS whose name would be "the name of the OS required by the package's components" - you might need a list such as linux,macos,ios,solaris,freebsd.

And, for OS-Version, you'd need minimum versions for multiple OSes.

My inclination would be to remove those attributes from the specification, or deprecate them, and wait until a clear need for them is established, and then, based on the requirements for such an attribute, specify attributes that address those requirements.

I can add in meson that we have basically this same setup, and have exactly the problem described here. My experience is that you need:

• kernel
• libc (glibc, bionic, musl, etc)
• userland (gnu, android, ios, macos, tvos, etc)

I agree. I don't care about the kernel. GNU/Linux, Android/Linux, and musl/Linux are all very different beasts for core compatibility. I suppose one could just write for Linux directly (a la Golang, though there are other issues around Golang content showing up in CPS files), but everyone else uses a C library of some kind on Linux.

Would a target triple (and possibly with a minimum version requirement) be sufficient here?

Can we avoid the target-triple? There's sevearl different variants of triples (llvm, gnu, at least a couple of others). I'd rather specify them as unique fields.

I think it is useful to have the kernel though, from a cross compilation point of view. It lets you do some basic sanity checking on the consumer side, and it's likely useful from some of the odd hybrids in debian and gentoo (debian-kfreebsd, which is the freebsd kernel, but a gnu based userland and glibc, for example).

And actually, the more I think about it, mesa could use the kernel-version field. We generally do have a minimum version for UAPi reasons. It's not likely relevant for other OSes, because of the tight coupling between the userland and kernel.

Whether the target triple is a string or an array of 3 strings is not material to me :) . The information is what's important.

everyone else uses a C library of some kind on Linux

...which is why there is C-Runtime-Vendor (and -Version, and Cpp-Runtime-* and Clr-*.) Except for userland (and its not clear why we need that, or how it would be used sanely)

I should also note that I'm not sure every package should even bother to report the kernel used. I think the original intention was to record the information and leave it up to the consumer to know if it cares (although, realistically, I don't expect people to be mixing packages built against different kernels very often), but maybe we need to give more thought to whether we need to decide when generating a package if it's important to report the kernel, with the implication that any package reporting what kernel it used will only work with that specific kernel.

That said, I suspect the main point of reporting the kernel was using it as a proxy for the binary format (e.g. PE vs. ELF). But maybe that's something else that should be its own attribute?

Ultimately, of course, the objective is to determine platform compatibility, which is a combination of system components (runtime libraries and, for some software, the kernel), ISA, binary format, and possibly other attributes.

Kernels support a variety of binary formats. DOS, ELF, a.out, Linux supports all kinds with binfmt_misc. I suspect that Kernel will mostly be useful for kernel-specific libraries such as libkeyutils (for Linux), WhateverKit (macOS/iOS), etc.

Note that ABI is also down to compiler flags like -ffast-math, -fPIC, /MT, and other things.

We need userland. If you're cross compiling say from macos/darwin to ios/darwin you need to know that. It's important, and this is a very real limitation in meson right now.

Note that ABI is also down to compiler flags like -ffast-math, -fPIC, /MT, and other things.

On that note for C++ it might be nice to have fields for exceptions and rtti as well, can't remember if those are already specified or not.

Kernel is also a nice sanity check when cross compiling. Being able to match that the declared host is "windows" and the cps file I got is for "windows" helps catch errors early. I want to error at configuration time rather than build time if possible.

As far as stuff like -ffast-math and such... yeah... that's not well specified right now (though I believe the hope was that required compile flags would help), because that sort of thing is in general not well specified. Ultimately, we're trying to solve a problem that is rather open-ended. We should cover the "obvious" and "well defined" aspects thereof, but at some point I suspect things are just going to fall apart in more exotic corner cases. Fortunately, those rarely occur in the wild outside of tightly integrated environments.

If we can at least cover the really, really obvious cases (c++ rtti, for example), I think that's good enough.