Declared here, defined there, Ceedling can't seem to find it

[jnz86]

Using Ceedling and Unity inside VSCode with TestRunner,

• Testing test_file.c
• includes file.h at lib/module/. Paths in yaml are correct, includes /lib/**
• file.h declares a function additional_function() that lives in file_additionals.c

I can't seem to get Ceedling to look for additional_function() inside file_additionals.c. I bring in file.h and everything in file.c works fine, but it seems to refuse to look elsewhere for this. It's such a simple scenario, but I have been plugging away at it for hours.

Am I missing obvious?

[mvandervoord]

Does test_file.c include the following:

#include "file.h"
#include "mock_file_additionals.h"

or does it include this:

#include "file.h"
#include "file_additionals.h"

[jnz86]

Neither.

Yea, that’s the tricky thing I guess.

The additional functions are defined in the additional c, but still declared in the file.h. So the only thing to bring in is file.h, and everything in file.c is fine.

It’s like Ceedling isn’t importing the additional.c file because it doesn’t have its own additional.h.

I tried to explicitly add the file to paths / YAML, no luck.

[jnz86]

Anyone?

[mvandervoord]

You're correct about your assessment. Ceedling isn't pulling in additional.c because you haven't told it to. It knows what to import based on the #includes you've provided, and this isn't one of them.

There are a couple solutions. First, you could directly include the C file in your test:

#include "additional.c"

Second, you could create a header for additional.h, even if it's only used in tests (you could even put it in a test folder, instead of the normal source folder, so long as you tell ceedling that it might be there by adding the path to your includes list.)

The advantage of this second method is that it would make the functions in additional.c mockable, in the even that any of your tests require that.

[jnz86]

Great!

I guess I don't fully understand that C linkers seem to understand the A.h might have functions for B.c and look there around, and that Ceedling won't do that. This is valid and reasonable C. I also understand that this might be too much work for the Ruby system that is trying to build in the backend. Is this something that might be included some day if the issue was raised?

Ok, those are two decent options. I never thought to include the .c file, but agree with you that the likely better solution is to create a test-only header even though I don't have reason to mock these functions. I think it'll just be cleaner if I can get that to live in my tests folder away from the functions and C file containing them.

Perfect. One way or another I have something that will work. Thanks.

[jnz86]

Update...

As to #include "additional.c"... Definitely don't do this! It caches the .c file and at least in my test enviroment is not updating changes leading to some really crazy behaviors that seem like 1+1=2 would return false.

[mvandervoord]

"I guess I don't fully understand that C linkers seem to understand the A.h might have functions for B.c and look there around, and that Ceedling won't do that. "

Actually, you're misunderstanding the linker situation. A linker will only link the files you tell it to link. You have to specify ALL the files to link (it won't discover any of them). Ceedling is auto-discovering most of the files you need based on what's in your test file, to keep you from having to explicitly specify this in a separate file each time. There are tradeoffs to both approaches, but neither has the ability to know what to do without the user specifying it somewhere.