Includes and include paths

[Alexander Broekhuis <a....@gmail.com>]

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.

myfile.h:
#include <bundle/bundle_service.h>

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:

bundle_service.h
#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

Re: Includes and include paths

[Pepijn Noltes <pe...@gmail.com>]

Hi,



On Thu, Sep 18, 2014 at 7:26 PM, Alexander Broekhuis
<a....@gmail.com> wrote:
> 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.
>
> myfile.h:
> #include <bundle/bundle_service.h>
>
> 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:
>
> bundle_service.h
> #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..
>

I agree with the approach of adding a directory prefix to the
includes. It makes it more more clear where headers are coming from.

It can also acts as sort of a namespace, meaning that we could include
same named header files (of course struct/var/function names still
have to be unique). This will help preventing name collision.
If we not only change how we include headers, but also some naming
convention this could help in preventing name collision. What about if
for the once-only include macro we not only use the file name of the
header, but also the parent directory and the same goes for the
declared structs, types, etc. For example

//shell/command.h
#ifndef __SHELL_COMMAND_H_
#define __SHELL_COMMAND_H_

typedef struct shell_command *shell_command_pt;
typedef struct shell_command_service *shell_command_service_pt;

struct shell_command_service {
    shell_command_pt command;
    void (*exec)(shell_command_pt command);
}


#endif /* __SHELL_COMMAND_H_ */

WDYT?



Greetings,
Pepijn