Partials generation fail if an include has relative path

[mundodisco8]

Description

I found another quirk on the preprocessing of files to create partials. When the module to be "partialled" has an include with a path

#include "utils/header.h"

The relative path is cut out on the ceedling_partial_... files, and because the include now becomes #include "header.h", the compilation fails to find it.

I added a zip file with a compressed folder with the smallest reproducible example. It's the same structure as the example on the documentation, but I added a header.h with a silly typedef-ed enum, and modified Sensor_Init to return a value of that type.

This happens whether the #include is in the .h or in the .c of the module to be partial-ed.

It can be worked around by adding the absolute path of the header to the project.yml file (Ceedling is then capable of finding it).

partials.zip

Steps to Reproduce the Problem

1. Get the "sensor" example, as listed on https://throwtheswitch.github.io/Ceedling/1.1.0/testing-guide/partials/example/
   1. Create a new Ceedling project, and add :use_partials: TRUE.
   2. Create sensor.h and sensor.c and copy the contents, as per the documentation
   3. Create hal.h on test/support and add

   #include <inttypes.h>
   
   void HAL_SensorEnable(void);
   uint16_t HAL_SensorRead(void);

2. Create test_sensor.c and copy the contents, as listed in the example
3. Add a dependency that includes a relative path on it, e.g. #include utils/header.h

Expected Behavior

Ceedling can compile the tests and run them

Actual Behavior

The created partial files, ceedling_partial_sensor_impl.c and ceedling_partial_sensor_impl.h, have the relative path stripped and only show the name of the module on the include #include "header.h", which can't be found and the compilation fails

👟 Preprocessing Test Files
---------------------------
Preprocessing test file test_sensor.c...
🧨 EXCEPTION: 'Default Test File Full Preprocessor' (gcc) terminated with exit code [1] and output ⏩️
In file included from test/test_sensor.c:14:
build/test/partials/test_sensor/ceedling_partial_sensor_impl.h:5:10: fatal error: header.h: No such file or directory
    5 | #include "header.h"
      |          ^~~~~~~~~~
compilation terminated.
Executed Command: gcc -E -I"build/test/mocks/test_sensor" -I"build/test/partials/test_sensor" -I"test/support" -I"src" -I"build/vendor/unity/src" -I"build/vendor/cmock/src" -I"build/vendor/ceedling" -D"TEST" -D"CEEDLING_PARTIALS_PREFIX=ceedling_partial_" -D"UNITY_EXCLUDE_FLOAT" -D"CMOCK_MOCK_PREFIX=mock_" -DGNU_COMPILER -x c "test/test_sensor.c" -o "build/test/preprocess/files/test_sensor/full_expansion/test_sensor.c"

Specifications

• Version:

Ceedling => 1.1.0.pre.2-645b64a
----------------------
/home/joel/.local/share/gem/ruby/3.3.0/gems/ceedling-1.1.0.pre.2/

Build Frameworks
----------------------
     CMock => 2.6.3
     Unity => 2.6.3
CException => 1.3.4

• Platform: Ubuntu on WSL2

[mkarlesky]

@mundodisco8 Thank you for this. Sorry for the trouble.

This is actually not a Partials problem. This is a known issue for Ceedling generally. A sizable refactoring of file finding is necessary to deal with this properly (in the backlog). The stripping of leading relative paths is intentional.

The fundamental limitation is that Ceedling needs to know ahead of time all header files. If relative includes are used to "extend" a limited base set search paths, then the header files are not found at startup from the base set of search paths.

Usually, it's possible to deal with this simply by ensuring that all paths of all header files are represented in the includes path globs in your project configuration.

Of course, this is only a workaround and there remain edge cases where Ceedling's educated guessing can fail. A tricky spot is header files with the same name distinguished only by their relative include path.

Please see if a comprehensive set of include paths in your project configuration allows your test build to work and report back. Perhaps you already have done this? I'm not presently able to look at the project archive you included.

[mundodisco8]

Yeah, using globs I can make it work. Knowing that is a quirk of the system, I'm OK with it being closed. I don't have many of those, I will worry about it if and when I stumble on one of those includes where the path is the distinguishing factor.

Thanks

[mkarlesky]

Gonna close this issue but only for sake of basic hygiene. This issue and other related issues are “rolled up” in #1167.