Compiler and Linker Features¶
CPS supports a notion of compiler and linker “features”,
which are used to abstract requirements that consumers of a component
modify the default compiler and/or linker behavior
in order to deal with functional inconsistencies across tools.
While it is ultimately up to the build tool
to determine how to map features to tool invocation flags,
it is clearly beneficial to attempt to standardize
a set of “well known” features.
Known features shall be case-insensitive,
however compiler specific portions might be case sensitive.
(For example, warn:error and Warn:Error
are the same feature,
but warn:foo and warn:Foo
should be treated as different,
unless the tool has sufficient knowledge
of the compiler to know otherwise.)
Compiler Features¶
c99¶
The component’s public interface
makes use of features included in ISO/IEC 9899:1999.
Code using the component should be compiled
in a mode which supports ISO/IEC 9899:1999 (e.g. -std=c99 or later).
c11¶
The component’s public interface
makes use of features included in ISO/IEC 9899:2011.
Code using the component should be compiled
in a mode which supports ISO/IEC 9899:2011 (e.g. -std=c11 or later).
cXX¶
This is a placeholder for later versions of the ISO/IEC 9899 “C” standard.
It is strongly recommended that CPS implementations be proactive
about supporting current and future language specifications
(e.g. ISO/IEC 9899:2017, spelled c17).
In order to avoid the need for continuous updates for features whose spelling and meaning is readily inferred, this specification does not attempt to list these exhaustively.
c++03¶
The component’s public interface
makes use of features included in ISO/IEC 14882:2003.
Code using the component should be compiled
in a mode which supports ISO/IEC 14882:2003 (e.g. -std=c++03 or later).
c++11¶
The component’s public interface
makes use of features included in ISO/IEC 14882:2011.
Code using the component should be compiled
in a mode which supports ISO/IEC 14882:2011 (e.g. -std=c++11 or later).
c++XX¶
This is a placeholder for later versions of the ISO/IEC 14882 “C++” standard.
It is strongly recommended that CPS implementations be proactive
about supporting current and future language specifications
(e.g. ISO/IEC 14882:2014, spelled c++14).
In order to avoid the need for continuous updates for features whose spelling and meaning is readily inferred, this specification does not attempt to list these exhaustively.
gnu¶
The component’s public interface makes use of features which are GNU extensions. Code using the component should be compiled in a mode which supports GNU extensions. (Note that this is orthogonal to specifying a language level.)
threads¶
Code using the component should be built
with run-time threading support.
On Windows, this would typically be used
to select the multi-threaded CRT library
rather than the single-threaded CRT.
On POSIX platforms, it typically indicates
that the application should be built with -pthread.
nowarn:...¶
Code using the component should either
enable (warn) or disable (nowarn)
the specified warning.
The warnings are compiler specific,
e.g. warn:reorder (GCC, Clang)
or warn:4513 (MSVC).
Tools are expected to recognize if a warning is applicable to the compiler and source language being used (e.g. by attempting to build a test program with the warning in question), and to ignore the feature otherwise.
nowarn:error¶
Code using the component should either
treat all warnings as errors (warn:error),
or should not treat warnings as errors (nowarn:error).
noerror:...¶
Code using the component should either
enable (error) the specified warning,
additionally promoting it to an error,
or should not treat the specified warning
as an error (noerror).
As with nowarn:...,
the warnings are compiler specific.
Note that noerror traditionally does not indicate
whether the specified warning should be issued or not,
only that if it is issued, it should not be promoted to an error.
Linker Features¶
threads (deprecated)¶
Implementations should treat this
as if the compile feature threads was specified.