search

PX4 / DriverFramework

Operating system and flight stack agnostic driver framework for POSIX (Linux, NuttX, Mac OS, QNX, VxWorks).
82 stars 132 forks source link

framework: Attempt to check i2c-dev.h for sanity #237

Closed sfalexrog closed 5 years ago

sfalexrog commented 5 years ago

This is a part of a possible fix for https://github.com/PX4/Firmware/issues/11137

This should not interfere with standalone builds of DriverFramework, but should check whether i2c-dev.h file on a builder's system is sane when built as a part of PX4 firmware.

Signed-off-by: sfalexrog sfalexrog@gmail.com

sfalexrog commented 5 years ago

Not quite. The linux/i2c-dev.h header file seems to be provided by two packages in 16.04: the first one is linux-libc-dev (the version it provides contains some defines and definitions for i2c_smbus_ioctl_data and i2c_rdwr_ioctl_data structs), the second one is libi2c-dev (which, for some reason, seems to contain an older version of linux/i2c.h with a definition for i2c_msg struct, along with some helper smbus functions).

I've posted both versions here: https://gist.github.com/sfalexrog/4f9c4465e5335e803f7d36c138dbc9f4

Curiously enough, installing both linux-libc-dev and libi2c-dev (in that order) results in the original linux/i2c-dev.h header being renamed to linux/i2c-dev.h.kernel.

julianoes commented 5 years ago

Wow that's weird. Well anyway, if your fix solves this for us, I'd say we merge it.

zsigmondszilveszter commented 5 years ago

@sfalexrog thanks for your fix, it supposed to solve my problem, but there is a small problem. Where does that "check_i2c_dev_h" COMMAND come from, because in my case the first cmake's IF from your PR (which checks whether the check_i2c_dev_h COMMAND exists or not) returns false (command doesn't exist).

sfalexrog commented 5 years ago

@zsigmondszilveszter This was supposed to be a two-part PR (the other one is in the firmware repository: https://github.com/PX4/Firmware/pull/11138, issue is described here: https://github.com/PX4/Firmware/issues/11137). To be honest, I'm not sure this should be relevant: the offending package has been updated in Ubuntu 18.04+ and Debian Buster+, and should no longer interfere. As a last resort, you could probably use Docker to build the firmware and run your SITL, though to get adequate performance you should try and expose your GPU to Docker (this repo could be a good starting point if you're running a GPU with open drivers).