Location of header files

Development archive
1

Dear rioters,

writing a new application for RIOT, I'm stumbling once again about the same old question: what would be the best way to store and include header files?

Currently most of the header files are located within an include subdirectory of the module's directory, e.g. headers for the kernel itself are found in core/include or headers for the lpc2387 are found in cpu/lpc2387/include. However, some headers are stored in more generic include directories, one level above the module directory (e.g. sys/include) or even directly within the same directory as the C files (e.g. sys/net/sixlowpan or drivers/cc110x/).

This situation is clearly poor and unsatisfying. Additionally, it raises the question about how to include the headers into C files. Should each application add every single include path to its Makefile and then just put a   include "foobar.h" into the source code or is it "better" to include relative paths like   include "sys/foo/foobar.h" ?

I really think we should tidy up this mess once and for all. So, what do you prefer? Put all headers into a generic path (like *nix system do)? Something like RIOT/include/. Or enforce the policy to store headers closely to the corresponding C files? And if so, would you prefer separate include directories or mingle source and header files?

Personally, I would vote to locate header files into an include subdirectory of the corresponding module. In my opinion, this is the cleanest solution and obeys RIOT's modularity best. I would then configure the Make system in a way, that include paths are set accordingly to the used modules in the application's Makefile. Whaddayathink?

Cheers, Oleg

2

Hi,

3

Hey all,

maybe we should collect requirements and derive from those:

1. make it easy to have self-contained modules -> includes must be whithin the module's directory

2. we like to have the includes seperated from .c files -> have a include/ per module

3. we like to write "#include "sixlowpan.h" -> the module's include path must be in "-I" list of the preprocessor

4. we (as in each of us) like our own "util.h". So combined with 3., to avoid name-clashes, we need to code the module's name in the include file's path- or filename

All in all, I agree with Martin on

module/include/module.h (-> #include "sixlowpan.h") module/include/module/foo.h (-> #include "sixlowpan/util.h")

But include/module.h should only export the API and everything needed to use the module, module/*.h contain the module's internal stuff.

Depending on the module, a "include/module_bar.h" might make sense, exporting optional functionality. (-> #include "sixlowpan_over_wifi.h")

Because of 3., I'd also agree with Oleg that the module's include path should be added to INCLUDES by the build system if the module is actually used.

Cheers, Kaspar