Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should CMake exports for include variables used for average workflow? #371

Open
cerna opened this issue Jan 23, 2022 · 0 comments
Open

Should CMake exports for include variables used for average workflow? #371

cerna opened this issue Jan 23, 2022 · 0 comments

Comments

@cerna
Copy link
Contributor

cerna commented Jan 23, 2022

This idea come when I tried to do simple porting of the bb_gpio in #369. (The example is available in 4da9215caf4954c2e6d628ca9a8b37308d801db6.)

The basic idea for HAL module projects (or shared libraries, or executables, anything which extends or depends on Machinekit-HAL) was that they will include the find_package call in theirs CMakeLists.txt file and then add required targets like Machinekit::HAL::Managed-Runtime or Machinekit::HAL::Managed-HAL to target_link_libraries call and maybe call some exported functions like export_rtapi_symbols:

...
find_package(
  Machinekit-HAL
  COMPONENTS Managed-Runtime Managed-HAL
  REQUIRED)
...
target_link_libraries(
  new_module PRIVATE Machinekit::HAL::managed_hal Machinekit::HAL::managed_runtime
)
...
export_rtapi_symbols(TARGET new_module)
...

This is all good and fine for building the module so it can be loaded into HAL, however it is inadequate for the normal workflow of Machinekit-HAL. For example, Machinekit-HAL's rtapi_app loader presumes that the modules will be prefixed with mod instead of lib (modand2v2.so for and2v2), that they will be in specific directory (depending on build setting, on Debian amd64 normally in /usr/lib/x86_64-linux-gnu/machinekit/hal/module/managed) etc. Some of these informations could be passed from the Machinekit-HAL as part of the export files, not all of them, because the CMAKE_INSTALL_PREFIX should still be passed by user, but the general path differences folders for executables, modules and whatnots, so depending project would then call:

set_target_properties(
  bb_gpio
  PROPERTIES OUTPUT_NAME "new_module"
             PREFIX "mod"
             LIBRARY_OUTPUT_DIRECTORY
             "${MACHINEKIT_HAL_UNMANAGED_MODULE_OUTPUT_DIRECTORY}")

install(TARGETS bb_gpio
        LIBRARY DESTINATION "${MACHINEKIT_HAL_MANAGED_MODULE_DIRECTORY}"
                COMPONENT New_Module_Managed_Module_Drivers)

or something similar and would not need to locally reinvent these paths or other variables.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant