celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Includes and include paths
Date Thu, 18 Sep 2014 17:26:15 GMT
Hi all,

Currently we use includes without a prefix, and in the CMake files the
include path is set to the directory with the headers.
During installation the Celix headers are installed in
<install_path>/include/celix, while the headers for different bundles are
installed in <install_path>/include/celix/<bundle_name>/.

This isn't necessarily a problem, a user can simply
setup <install_path>/include/celix
and <install_path>/include/celix/<bundle_name> as include paths, resulting
in simple includes. While this works, this means that a user of a certain
bundle header, needs to setup include paths for all other (bundle) headers
used by that header.

But, when using Celix as a library (so not developing within the project
itself) I like the use of the bundle_name prefix in the include. This makes
it really clear where a header comes from. But since the framework itself
at the moment does not use this, this means that header files cannot be
found if a included header includes a bundle header itself again.

#include <bundle/bundle_service.h>

#include "otherbundle_service.h"

bundle/bundle_service.h can be found since ../include/celix is on the
include path and bundle/bundle_service.h in that same location. But now
otherbundle_service.h cannot be found, since ../include/celix/otherbundle/
is not on the include path. The user needs to add that one as well to make
it work.

If we change the header paths in Celix itself, it would be:

#include "otherbundle/otherbundle_service.h"

And there won't be a problem for Celix development as well as for users.

What do others think? If we want to support this, we need to shuffle the
paths of the headers in the framework. While a rather simple task, this
probably also has impact on existing users, so I don't want to rush this..

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message