D1864R0
Defining Target Tuplets

1. Revision History

1.1. Revision 0

Initial release. 🎉

2. Motivation

One of the more difficult things in the vast breadth of build systems is declaring what system architecture, vendor, operating system, and ABI is used when compiling for a given platform. In some cases, these names are chosen at random by various implementations and differ from each vendor. While some time ago these would have been called "Target Triples", in practice they have been "Target Tuplets".

This paper aims to define the concept of a target tuplet and how they can be consumed by build systems, toolchains, and users alike. This paper does not attempt to define or limit existing target tuplets and instead defers this "definition list" to a separate Standing Document. The reason for this is that updating target tuplets with a Technical Report or Standard requires several years to be updated and voted in. This can’t react to existing practices, while a Standing Document can be updated at each plenary vote.

This paper might give examples of existing target tuplets, but this is for demonstration purposes and not to be taken as a guarantee that the tuplet will exist in such a form in the future.

Lastly, this paper also does not attempt to define a sysroot. A separate paper will be written at a later date to formalize the concept.

3. Design Considerations

A target tuplet is written (in utf-8) as a series of words (text), delimited via a hyphen (–). The current layout of a target tuplet is borrowed from clang, as it is more well defined than others.

Typically, a target tuplet does not infer floating point ABI, CPU specific intrinsics, or FPU specific intrinsics. These are more granular and defining them at a broad scope is, in the authors opinion, fruitless.

Lastly, a target tuplet can be considered "ill-formed, no diagnostic required" if an incorrect sequence is put together and passed to the compiler. For example, specifying mips-ibm-cuda-macho as a target would most likely not work in any existing compiler (at the time of this writing). Instead, it is up to users and build systems to ensure that these incorrect sequences do not make their way to the compiler. This differs from clang’s approach, which is to convert any unrecognized entries as unknown, and then infer specifics.

4. Wording

¹A target is the architecture, ABI, and operating system (or lack thereof) a compiler is generating code for.

²A target tuplet entry or entry is defined as a UTF-8 sequence, also known colloquially as a word.

³A target tuplet is defined as a four entries, delimited via a hyphen (–).

⁴A supplied target tuplet is a sequence of entries, delimited via a hyper (–), with a minimum of one entry, and a maximum of four entries.

⁵When a supplied target tuplet is provided to a compiler, or build system, the missing entries are to be filled in with the catch-all element unknown.

⁶When a compiler is given a target tuplet that it is unable to rectify or target, the invocation of the compiler is considered ill-formed, no diagnostic required.

⁷When a build system is given a target tuplet that it is unable to rectify or target, the build system is to alert the user at the earliest possible time that the compiler cannot be safely invoked in such a manner.

⁸The first entry in a target tuplet is to specify the CPU architecture that the compiler will be targeting. Details about which specific CPU are not to be defined. Revisions of the CPU architecture are permitted to be attached (e.g., arm, armv6, armv7a), but only if the CPU architecture is defined as having revisions.

⁹The second entry in a target tuplet is to specify the vendor that has provided the given toolchain. This field is optional, as open source compilers can have a theoretically infinite number of vendors, one per each person compiling it. However, it is highly recommended that compiler vendors have a specific name for this field, to differentiate between similar compilers provided by different vendors

¹⁰The third entry in a target tuplet is to specify the operating system that is being targeted. In the event that the target is devoid of an operating system, the bare metal specifier none is to be used.

¹¹The fourth entry in a target tuplet is to specify the ABI being targeted. This can include ELF, Mach-O, COFF, GNU, and others. The specifics of the ABI being targeted do not matter, simply that there is an ABI provided by the compiler.

¹²A catch-all entry named unknown may be used in a supplied target tuplet to allow toolchain specific information to be inferred by the build system.