@LeStarch and I have discussed the following issue with the path names of header files included from config:
In a typical project, many headers in config exist in two versions: the default one in [fprime root]/config and the project-specific one in [project-root]/config.
The build system includes only one of [fprime root]/config and [project root]/config in the list of include header paths. The idea is that for any header H.hpp, only one of [fprime root]/config/H.hpp and [project root]/config/H.hpp is included, and this choice is made consistently everywhere.
However, if one writes #include "config/H.hpp", then there is a danger that the wrong header will be picked up, because [fprime root] and [project root] are both in the list of include paths.
The current approach is to write #include <H.hpp> when H.hpp is a manually written file (so that there's a corresponding version in [fprime root]/config). For example, we write #include <FpConfig.hpp> and not #include "config/FpConfig.hpp". However, (1) this approach is brittle, because the compiler cannot enforce it; and (2) for auto-generated files like FppConstantsAc.hpp we need to write #include "config/FppConstantsAc.hpp" to distinguish files in located in config from files located elsewhere.
A better solution would be to allow and require the spelling #include "config/H.hpp" everywhere, and have the build system ensure that this spelling specifies an unambiguous location. We could do this by putting config in another directory, and having the build system place that directory, instead of config, in the list of include paths.
Here is the suggestion from @LeStarch:
I would suggest for F´:
default/config/….headers…
I would suggest for projects:
project/config/….headers…
@LeStarch and I have discussed the following issue with the path names of header files included from
config:configexist in two versions: the default one in[fprime root]/configand the project-specific one in[project-root]/config.[fprime root]/configand[project root]/configin the list of include header paths. The idea is that for any headerH.hpp, only one of[fprime root]/config/H.hppand[project root]/config/H.hppis included, and this choice is made consistently everywhere.#include "config/H.hpp", then there is a danger that the wrong header will be picked up, because[fprime root]and[project root]are both in the list of include paths.#include <H.hpp>whenH.hppis a manually written file (so that there's a corresponding version in[fprime root]/config). For example, we write#include <FpConfig.hpp>and not#include "config/FpConfig.hpp". However, (1) this approach is brittle, because the compiler cannot enforce it; and (2) for auto-generated files likeFppConstantsAc.hppwe need to write#include "config/FppConstantsAc.hpp"to distinguish files in located inconfigfrom files located elsewhere.A better solution would be to allow and require the spelling
#include "config/H.hpp"everywhere, and have the build system ensure that this spelling specifies an unambiguous location. We could do this by puttingconfigin another directory, and having the build system place that directory, instead ofconfig, in the list of include paths.Here is the suggestion from @LeStarch: