[riot-devel] Location of header files
kaspar at schleiser.de
Thu Jun 20 14:28:01 CEST 2013
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
On 06/20/2013 01:09 PM, Oleg Hahm wrote:
> 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?
More information about the devel