XCommon had LIB_INCLUDES and LIB_EXPORT_INCLUDES to separate the include directories for a module or static library to avoid clashes between headers used internally in the module/archive code and the headers containing the public API as used by the application.
For example, if a static library has a header with a common name (eg errors.h) which is needed to build the archive, that directory must be added to the include search path. But that header is not part of the public API of the static library, so it isn't needed when linking into an application. There may be another errors.h header that is needed for the application, but XCommon CMake is reusing the same include directories for both use-cases and the wrong header may be included, leading to a compilation failure.
Need to handle include search paths for different types of header:
internal header required for the module/static library build
public API header for linking into an application
(for static libraries) header for additional sources which are compiled and linked when the application is built
xross
commented
2 months ago
XCommon had LIB_INCLUDES and LIB_EXPORT_INCLUDES to separate the include directories for a module or static library to avoid clashes between headers used internally in the module/archive code and the headers containing the public API as used by the application.
For example, if a static library has a header with a common name (eg errors.h) which is needed to build the archive, that directory must be added to the include search path. But that header is not part of the public API of the static library, so it isn't needed when linking into an application. There may be another errors.h header that is needed for the application, but XCommon CMake is reusing the same include directories for both use-cases and the wrong header may be included, leading to a compilation failure.
Need to handle include search paths for different types of header: