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
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:
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:
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 theirsCMakeLists.txt
file and then add required targets likeMachinekit::HAL::Managed-Runtime
orMachinekit::HAL::Managed-HAL
totarget_link_libraries
call and maybe call some exported functions likeexport_rtapi_symbols
: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 withmod
instead oflib
(modand2v2.so
forand2v2
), that they will be in specific directory (depending on build setting, on Debianamd64
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 theCMAKE_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:or something similar and would not need to locally reinvent these paths or other variables.
The text was updated successfully, but these errors were encountered: