My hunch is that they don't care. If a rule says it'll create first, then doesn't, but succeeds, gmake is happily ignorant where mpp pedantically checks the result of every step :-(
There is some trickery in there: first is a phony target that depends on first.exe behind the scenes. If first.exe had succeeded (or with -k) it would have later built second.o independently of first.exe.
We would have to not shove in that extra rule
$(phony first): first.exe
but rather make first.exe an additional target of this rule. Would you like to explore how to do that better, and maybe submit a patch?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sometimes I add a dependency to an executable that otherwise gets created by an implicit rule, like
first: second.o
This works fine with gmake and mpp on linux, but on cygwin the dependency doesn't get picked up:
makepp: Loading makefile `/c/docs/sandbox/make/makepp/exe_suffix/makefile'
makepp: Scanning `/c/docs/sandbox/make/makepp/exe_suffix/first.cpp'
makepp: Entering directory `/c/docs/sandbox/make/makepp/exe_suffix'
g++ -g -Wall -c first.cpp -o first.o
g++ first.o -o first.exe
first.o: In function `main':
/c/docs/sandbox/make/makepp/exe_suffix/first.cpp:6: undefined reference to `f()'
collect2: ld returned 1 exit status
makepp: error: Failed to build target `/c/docs/sandbox/make/makepp/exe_suffix/first.exe'
makepp: 1 file updated, 0 phony targets built and 1 target failed
makepp: error: $(prebuild first.exe) failed
$(prebuild first.exe) failed
Gmake works fine however.
hm, I wanted to add the files, but it looks like the forum won't let me do this, so I created a bug report instead:
: https://sourceforge.net/tracker/?func=detail&aid=2881158&group_id=43679&atid=437093
My hunch is that they don't care. If a rule says it'll create first, then doesn't, but succeeds, gmake is happily ignorant where mpp pedantically checks the result of every step :-(
There is some trickery in there: first is a phony target that depends on first.exe behind the scenes. If first.exe had succeeded (or with -k) it would have later built second.o independently of first.exe.
We would have to not shove in that extra rule
$(phony first): first.exe
but rather make first.exe an additional target of this rule. Would you like to explore how to do that better, and maybe submit a patch?