-
Philippe Gerum authored
We need a way to provide copperplate headers which expose distinct implementations and/or declarations for the same feature set depending on the current core we compile for. Typically, tracing support and function wrappers come to mind. To this end, two new sub-trees are available, namely: - include/cobalt/copperplate - include/mercury/copperplate The autoconf bits set the proper include directive in the CFLAGS so that client code may pull the right header as <copperplate/header.h>. Obviously, core-specific copperplate headers shall not conflict in name with the generic ones available from include/copperplate (unless we really want to play the include_next game). To be future-proof, sub-Makefiles should list include directives so that core-specific copperplate headers are always matched before generic ones.
f058f3c2