Open dwmw2 opened 3 years ago
The solution here is probably to start guaranteeing that the final component of the include pathname will be openzwave
and then for the pkg-config file to add both the parent and the actual directories to CFLAGS.
That way we don't immediately break applications which include the ambiguous
Or a trick like this..
# cd /opt/zwave/include/openzwave
# mkdir openzwave
# mv * openzwave
# for a in `find openzwave -name \*.h` ; do echo -e "#warning Please include <$a> not just <${a#openzwave/*}>\\n#include <openzwave/${a#openzwave/*}>" > ${a#openzwave/*}; done
The standard installation of libopenzwave puts header files into a certain directory (e.g /usr/local/include/openzwave) and then the pkg-config file libopenconnect.pc adds that directory itself to the compiler's include search path, so that header files are included by an application as e.g.
This is a problem because those header names are very ambiguous. Especially on case-insensitive systems where any "node.h" on the compiler include path is going to get included instead.
Applications can't just do
#include <openzwave/Node.h>
because the actual include directory is configurable and might not even haveopenzwave
as the final component of the pathname — and even if it did, the parent directory (in the above example/usr/local/include
) might not even be on the compiler's search path anyway; OpenZWave's own pkg-config file would need to specify it correctly.This is causing build failures on Mac OS for Domoticz: https://github.com/domoticz/domoticz/issues/4114