You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In recent years the CMake build has been adopting the current best-practices whenever feasible to do so, and moving away from features that have been marked as obsolete or deprecated.
Use interface properties to propagate compiler flags, definitions, etc to dependencies, rather than setting "magic variables" that need to be known by the dependency
Prefer target_include_directories as opposed to include_directories at directory scope
Prefer target_compile_definitions as opposed to add_definitions at directory scope
Additional context
It is not currently possible to propagate the UT coverage flags if OSAL and the application are in separate builds.
Using the target-scope features and interface libraries is of particular benefit to making a proper OSAL "package" that can be compiled and linked separately from the application (see #1284)
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Sep 23, 2022
Use target properties to define interfaces and compiler definitions
rather than referencing global variables or using "known" paths in
other modules. This better aligns with current practices and creates
a more robust build environment that is less dependent on specific path
names existing in a given module.
This adds an "osal_public_api" interface target that contains the paths
to the public API headers as its INTERFACE_INCLUDE_DIRECTORIES and any
required compiler definitions as its INTERFACE_COMPILE_DEFINITIONS
property. Applications should use this rather than referring to the
"${OSAL_SOURCE_DIR}/src/os/inc" include path directly.
Is your feature request related to a problem? Please describe.
In recent years the CMake build has been adopting the current best-practices whenever feasible to do so, and moving away from features that have been marked as obsolete or deprecated.
target_include_directories
as opposed toinclude_directories
at directory scopetarget_compile_definitions
as opposed toadd_definitions
at directory scopetarget_link_libraries
should include the scope keyword (PUBLIC/PRIVATE) rather than the "bare" signature (also noted by CFE user in add_cfe_app uses deprecated call to target_link_libraries cFE#2141)Describe the solution you'd like
In particular - the following specific areas should be modernized:
osal/CMakeLists.txt
Line 89 in 38559d4
osal/CMakeLists.txt
Lines 154 to 163 in 38559d4
osal/CMakeLists.txt
Line 282 in 38559d4
osal/CMakeLists.txt
Lines 354 to 355 in 38559d4
Additional context
It is not currently possible to propagate the UT coverage flags if OSAL and the application are in separate builds.
Using the target-scope features and interface libraries is of particular benefit to making a proper OSAL "package" that can be compiled and linked separately from the application (see #1284)
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: