how to use instcomp with new packaging scheme #369

Activity

1. jallwine commented on Jan 20, 2022

   

   jallwine

   on Jan 20, 2022

   ContributorAuthor

   More actions

   This may be tied to #361.
2. cerna commented on Jan 20, 2022

   

   cerna

   on Jan 20, 2022

   Contributor

   More actions

   @jallwine,

   I imagine I've installed CMake incorrectly or need to perform some extra steps. Any ideas?

   This could be caused by a bug which should be repaired in a PR #364. The issue was that not all parts were installed correctly and it panicked on it. As nobody merged it in 18 days, I am going to do it. Hopefully, it will help.

   I followed these instructions for building machine-hal packages: http://www.machinekit.io/docs/developing/machinekit-developing/

   Yes, sorry, I haven't yet updated the building documentation. (Well, I think I will need to pretty much rewrite it [minimally] as the documentation is pretty much useless right now. I am tracking it in machinekit/machinekit-docs#327.)

   It seems like instcomp now needs an install directory to be specified?

   Yes, the reason behind it is that by Debian rules, you should ideally install the locally built binaries under /usr/local/* as the the /usr/* root should be used for packages. It's not great, because the loader still looks for them under the /usr/lib/x86_64-linux-gnu/machinekit/hal/module/*, but specifying the path seemed like best solution at the moment for it.

   Down the line, the comp and instcomp scripts will need to be separated or maybe merged into just *.(i)comp -> *.c translators and then separate CMake generator/executor script which will take the C file and builds and installs it.

   Also, the searched paths will need a better configuration.

   Sorry, I forgot that there are no pre-build statically linked binaries from Kitware with the latest CMake for armhf. That's a problem for which I will need to find a solution.

   Also, I am not sure about the paths for the pru_generic firmware, respective if the loader module will be able find it. Maybe it will need a massaging/bugfix. (Sorry in advance.)
3. jallwine commented on Jan 21, 2022

   

   jallwine

   on Jan 21, 2022

   ContributorAuthor

   More actions

   Thanks @cerna! I rebuilt the machinekit-hal packages and tried again. Now I'm getting this error:

   CMake Error at CMakeLists.txt:21 (add_library):
     Target "bb_gpio" links to target "Machinekit::HAL::managed_hal" but the
     target was not found.  Perhaps a find_package() call is missing for an
     IMPORTED target, or an ALIAS target is missing?
   

   In case it helps, these are the commands I'm running to give this a go:

   sudo apt-get install libgpiod-dev
   
   git clone https://github.com/pocketnc/bb_gpio
   cd bb_gpio
   mkdir lib
   EXTRA_LDFLAGS="-lgpiod" instcomp --install=lib bb_gpio.c
   
4. cerna commented on Jan 22, 2022

   

   cerna

   on Jan 22, 2022

   Contributor

   More actions

   Muhehehe, @jallwine, with one strike you sunk the comp/instcomp/CMake triplet.

   Well, yeah, it's not working.

   The main points are:

   • The instcomp (and comp too) is missing link to component Managed-HAL
   • I was not thinking about this use case (bring your own C code), so only the bb_gpio.c file was copied to build, not the header file
   • It does not take the EXTRA_LDFLAGS into account

   There will be other changes needed for the codebase because of namespacing. Frankly, it was easier to write it by hand (example in cerna/bb_gpio), than make the instcomp work as expected. (And what I still don't get is how the stdio.h header was propagated.)