... | ... | @@ -486,25 +486,16 @@ COMPILE_TIME_ASSERT((size_t)SL_ECU_INFO__IMAGE_TYPE_COUNT == ARRAY_COUNT(image_t |
|
|
|
|
|
## Use Relative Includes
|
|
|
|
|
|
There are two ways to design a code module:
|
|
|
Shown below are two ways to include a code module. We recommend going with Option 1 for the reasons mentioned below.
|
|
|
```c
|
|
|
// Option 1
|
|
|
#include "sl_data_carrier.h"
|
|
|
```
|
|
|
Here, we do Compiler `-I` path resolution
|
|
|
|
|
|
* `#includes` are easier to maintain
|
|
|
* Immune to code module path changes
|
|
|
|
|
|
```c
|
|
|
// Option 2
|
|
|
#include "../buffers/sl_data_carrier.h"
|
|
|
```
|
|
|
Here, we are doing absolute path Includes. This prevents us from having ambiguous includes and prevents the customer from having to `-I` all include files.
|
|
|
|
|
|
In the first example, we expect that the code integrator (customer) has resolved the paths to be able to build the code module. In the second example, we explicitly rely on a folder structure to pull in appropriate header files.
|
|
|
|
|
|
**We chose to go with `Option 1` because:**
|
|
|
|
|
|
* If files move around, we will not have to change code dependencies
|
|
|
* If there are conflicts to file includes (customer `common.h` vs. our `common.h`) then we have plans to mitigate the problem
|
... | ... | |