Support for POSIX and Single UNIX Specification configuration information

[jscott0]

Hi,

In most of the following I'm only really speaking about the C programming language and the ecosystem around it.
For over three decades, the POSIX and Single Unix Specification standards have specified some minimal requirements to aid application portability. These include the _POSIX_C_SOURCE and _XOPEN_SOURCE feature test macros for applications to request conformance to the standards as well as options and option groups that applications can query support for. A summary of what I'm talking about can be seen here in SUSv5/POSIX Issue 8 published this year. Meanings of many of those codes are prescribed here.
Importantly, in order to indicate to the operating system ("the implementation") that conformance to a particular standard is required and to control the namespace, it is mandatory that conforming applications define the _POSIX_C_SOURCE or _XOPEN_SOURCE feature test macros to an appropriate value. It is technically undefined behavior if an application does not set at least one of these, except possibly if the application conforms to the ISO C standard and the OS happens to accommodate that as well.

The standards also prescribe programming environments which roughly correspond to the concept of an ABI and which some applications may need to ask for. The syntax for command-line arguments with a standard C compiler and what can be reliably found in that environment are also specified.

With the C programming language aside, some operating systems may need certain environment variables like PATH to be set to get a conforming environment, and there are ways to discover these. Without that precaution, there's no assurance that find_program('sh') will find a shell or merely some other program with the same name.

The application development features in these standards are deliberately minimal. Especially for dependency management, Meson has a lot to offer even for applications seeking strict conformance. In my tinkering with Meson, I find that I have to write a lot of boilerplate code to ensure that things like _POSIX_C_SOURCE are set up correctly. Since Meson provides a large superset of features that can be done with makefiles, it would be helpful if Meson could "inherit" the ability to examine and control the compilation environment that applications need.

To set the appropriate feature test macros, I currently have to run getconf _POSIX_VERSION to find what a good value is. find_program(..., native: false) says that it can fall back on a native executable if one for the host isn't available, so this—as well as a "runnable" getconf not being available at all—throw a wrench into cross-compiling. To solve this, I've adopted the convention that people can set the (_)POSIX_VERSION variable in a cross file, and I'll use this to decide how to set _POSIX_C_SOURCE. This is a lot of re-inventing the wheel however.

Indeed, some of these concepts don't map nicely into Meson at all. Many of them do, however, so a Meson module that I could call like import('posix').getconf('_POSIX_VERSION') that would just always do the right thing seems like a clean mapping.

Conclusion

It's very cumbersome to write an application that conforms to international standards while reaping the benefits that Meson has to offer like improved dependency management and quality assurance features. The majority of use cases can be satisfied without having to stray too far from how Meson works and the approach it takes. Some of the biggest motivators for this sort of thing—ones I've been dealing with lately—involve cross compilation and embedded systems. Standards conformance is an especially big deal for applications in this sector and so Meson would really shine here.

By the lack of similar discussions, I understand that this is low on the priority list. My intention in writing this monologue is to express, from beginning to end, the problem space and the state of the art for anyone who happens to become curious.