Header files have ambiguous names.

[dwmw2]

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.

#include <Node.h>

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 have openzwave 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: domoticz/domoticz#4114

[dwmw2]

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 <node.h>; we can deprecate those include directives and move applications to <openzwave/Node.h> over time before finally dropping the directory itself from CFLAGS?

[dwmw2]

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