The providers for OpenLMI are intended to use common utility routines which are shared by all providers. These utilities are in the openlmicommon library. The definitions for the content of libopenlmicommon is in globals.h, when openlmi-providers-devel is installed globals.h appears in /usr/include/openlmi.

If you are building an openlmi provider outside of the openlmi package you should be able to find the definitions for the headers and library by a standard mechanism., pkgconfig is the standard mechanism. As it stands now one has to hardcode this information into your build, hardcoding should be avoided.

Also OpenLMI has adopted CMake as it's preferred build system. One should be able to follow CMake conventions for finding headers and libraries.

It is suggested that openlmi-providers-devel install a pkgconfig file. This would support both projects using CMake and those which do not and would follow existing Linux conventions (pkgconfig is fairly universal)

In a CMakeLists.txt file one could then have something like this:

find_package(PkgConfig QUIET)
pkg_check_modules(OPENLMI openlmi-1.0 REQUIRED)

include_directories(${CMAKE_CURRENT_BINARY_DIR}
                    ${CMPI_INCLUDE_DIR}
                    ${OPENLMI_INCLUDE_DIR}
                    )

target_link_libraries(${LIBRARY_NAME}
                      ${OPENLMI_LIBRARIES
                      ${KONKRETCMPI_LIBRARIES}
                      )

Note the use of ${OPENLMI_*} variables in the above snippet.

If you wanted to add CMake macros to explicitly set the header and library definitions one could do that as well, but a pkgconfig should still be provided because that's a standard mechanism and it would support projects not using CMake.

I expect a number of providers will be using the CMake pkgconfig support anyway for their other dependencies.

Bottom line: we need a mechanism which does not require hardcoding the include file location and library name into build scripts and works for external building.

P.S.: Should we consider renaming globals.h to something more specific? It's a bit generic for a public header and really doesn't convey it's contents.