Some background: I have a project based on ESP-IDF which has a complex builtin building system which you plug into with your own makefile (their documentation on using it).
This works fine (apart from occasional horrendous build times), but now I wanted to add a build target for unit tests for a component, which requires building this component against another project (the unit-test-app
).
So, I need another build target that calls another make
with another makefile and directory. Something like this works fine:
make -C $(path to unit-test-app) \
EXTRA_COMPONENT_DIRS=$(my component directory) \
TEST_COMPONENTS=$(my component name) \
ESPPORT=$(my serial port) \
-j clean app-flash monitor
But only if I execute it from bash. If I try to execute it from another makefile, it breaks either not finding some header files (the include path is different between the main and unit test project) or ignores the change of project (-C
argument) and executes the main project build.
What I tried:
- using
$(MAKE)
,$(shell which $(MAKE))
andmake
in the custom target - using
env -i $(shell which $(MAKE) ) -C ...
with forwarding required environment arguments to the child make - using
bash -l make -C ...
andbash -c make -C ...
What works but is a dirty hack: using echo $(MAKE) -C ...
in the make target and then running $(make tests)
from the command line.
As far as I know, this is an issue of the parent makefile setting something up in the environment that I did not separate the child makefile from. What else can I do to separate these two?
UPDATE: I have created an example project that shows the issue more clearly, please look at the top Makefile
of https://github.com/chanibal/esp-idf-template-with-unit-tests
I reproduced your situation as you are describing it and everything works fine, both if I call the inner
make
frombash
or from the outermake
.So there is something you are not telling us that is causing the failure.
On the other hand, I feel there are several irrelevant details in your description.
So, I suggest you try to further isolate the problem, removing irrelevant stuff, and reproducing the problem only from the description in your question, and then when you are doing it you will probably find out what is breaking. If not, then post here the minimal setup with all the other details that are needed for the failure to occur.
By the way, what you are doing is not good practice, so maybe just avoiding it would solve your problems.
What I mean is, there is one case and one case only, where recursive
make
is good practice:make -C ${directory}
where in
directory
you have a completely self-contained build, not using anything from the outside.It seems this is not the case for you, because you seem to be passing some outside location variables. This kind of recursive
make
is bad practice and should be avoided.