how to use instcomp with new packaging scheme

[jallwine]

I followed these instructions for building machine-hal packages: http://www.machinekit.io/docs/developing/machinekit-developing/
The only real change I had to do was to use the buildcontainerimage.py script in the debian directory rather than the scripts directory (which no longer exists). I built the deb packages for Debian Bullseye on armhf (as I want to run it on the Beaglebone Black). After building the packages, I installed them to a Beaglebone running Debian Bullseye using the following:

sudo dpkg -i *.deb
sudo apt-get -f install

I was able to start the realtime environment and instantiate some basic HAL components. Now, I'm trying to compile and install my own HAL components using instcomp (specifically this one: https://github.com/pocketnc/bb_gpio). It seems like instcomp now needs an install directory to be specified? (I get the following error: Error: Install path must be a single directory).

When I give it a path, it then complains with some CMake errors. First, I had cmake 3.18 installed (from Bullseye repositories), so it complained about that. I built CMake 3.22 from source (this took close to all day on my Beaglebone Black). Now when I run instcomp I get this:

CMake Error at CMakeLists.txt:16 (find_package):
  Found package configuration file:

    /usr/lib/arm-linux-gnueabihf/cmake/Machinekit-HAL/Machinekit-HALConfig.cmake

  but it set Machinekit-HAL_FOUND to FALSE so package "Machinekit-HAL" is
  considered to be NOT FOUND.  Reason given by package:

  File
  "/usr/lib/arm-linux-gnueabihf/cmake/Machinekit-HAL/MachinekitHALRTAPIPCITarget.cmake"
  is missing!

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

[jallwine]

This may be tied to #361.

[cerna]

@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.)

[jallwine]

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

[cerna]

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.)