1

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)) and make 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 ... and bash -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

Krzysztof Bociurko
  • 4,575
  • 2
  • 26
  • 44
  • 1
    Erm, `$(path to unit-test-app)` is _command substitution_ in _bash_, but it is expansion of the variable `path to unit-test-app` in _make_. These are two completely different things. Note: to pass `$` from a _make_ recipe unmolested through to _bash_, you must write `$$` in the _make_ recipie. – bobbogo Sep 22 '17 at 15:55
  • The `$(...) ` were for clarity only (guest that didn't help...), the real line in my makefile is: `$(MAKE) -C "${IDF_PATH}/tools/unit-test-app" EXTRA_COMPONENT_DIRS="${CURDIR}/components" TEST_COMPONENTS="hal" ESPPORT="${ESPPORT}" -j app-flash monitor` – Krzysztof Bociurko Sep 22 '17 at 17:29
  • And just checked, changing the line from `${...}` to `$(...)` doesn't fix this. – Krzysztof Bociurko Sep 22 '17 at 17:32
  • @Kyzysztof What do you mean by "But only if I execute it from bash"? The snippet you give is not valid _bash_ syntax. If you are executing it from _make_, then before _make_ passes the command to _bash_, it will first print out the line it is going to ask _bash_ to execute. What does that look like in both the working and failing case? – bobbogo Sep 25 '17 at 10:43
  • @bobbogo: added an example project, look at the Makefile there, it should clear up the issue. About bash, look at the difference between `tests` and `tests-hack` targets - the one I want to force to work is `tests` (and would execute it in bash as `make tests`). Currently I have the `tests-hack` target that I have to execute in bash as `$(make tests-hack)`, because it can output what I need to be executed, but cannot execute it in make. – Krzysztof Bociurko Sep 26 '17 at 11:28
  • @Kyzysztof Still confused. The error is not obvious unless the makefile you call requires the `"` to be part of the variable. Smelly if so. What does the command-line generated by _make_ look like? What do the error messages look like? What environment are you running under? – bobbogo Sep 27 '17 at 17:12

1 Answers1

0

I reproduced your situation as you are describing it and everything works fine, both if I call the inner make from bash or from the outer make.

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.

Mark Galeck
  • 6,155
  • 1
  • 28
  • 55
  • I have included an example project in the question. It's an almost minimal use case. As to bad practice, this is how this platform works. To test project internals, I have to wrap them in an external project that is a unit test runner. I could run this from an bash script, but a make target is just more elegant and works better with third party tooling. – Krzysztof Bociurko Sep 26 '17 at 11:39
  • 1
    @KrzysztofBociurko no, sorry, no such thing as "example project". Please, make a _really_ minimal case that reproduces the bug and post all the code here. I cannot imagine it should be more than 50 lines, total. – Mark Galeck Sep 26 '17 at 20:52
  • Well, the top `Makefile` there is that minimal case, the variables passed to the external make are required by the docs. The rest is just sources so the makefile has anything to work on and can be ignored. That is built against the ESP-IDF that is the library/environment with it's own build system (something I have no control over). The whole issue is integrating into the ESP-IDF's build system, which is what someone might call magical - so frankly there isn't much to cut out. And if I had any idea what is the issue in interacting with the ESP-IDF build system, there would be no question here. – Krzysztof Bociurko Sep 27 '17 at 09:50
  • @KrzysztofBociurko Like I said, I duplicated and could not reproduce the bug. You are essentially telling me, that you cannot further isolate the bug. I am sorry, no disrespect, but I don't buy it. I have never met a project case, no matter how complex, that one could not isolate the bug to a relatively few lines of code (and in the process, most likely solve the bug). It is always possible to isolate. If you disagree, let's agree to disagree but I can't help you. – Mark Galeck Sep 27 '17 at 12:05