%% Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> $(DDD_FILES):
>> @echo -- generating makefile: $@
>> @set -e; rm -f $@; \
>> echo "$(DFILE_HDR)" > $@; \
>> $(CXX) -M $(CXXFLAGS) $< > [EMAIL PROTECTED](PID); \
>> sed 's,^.*\.o[ :]*,$(@:%.d=%.o) $@: ,g' < [EMAIL PROTECTED](PID) >> $@; \
>> rm -f [EMAIL PROTECTED](PID)
ez> The command here is a single shell command, as evidenced by the
ez> backslashes before each newline. So Make doesn't regain control
ez> until this whole multi-line command returns.
The "set -e", in a POSIX shell, turns on "exit on error" mode; in this
mode the shell will exit immediately when any command line exits with a
non-0 code.
So, on UNIX, this command would exit immediately if the $(CXX) program
exits with a non-zero code, as Matt expects.
ez> I don't know how this worked on Cygwin for you, perhaps you used a
ez> different shell, or perhaps the Cygwin Make interacts differently
ez> with the shell.
I agree, though, that this must be an issue with the shell that make is
invoking: I can't see it being an issue with GNU make proper. The only
relationship between this problem and make could be which shell is
invoked or how the shell is invoked.
Matt: can you remove the "@" prefix to this command ("set -e; ...") so
we can see what exactly is being invoked here? Also, if you use -d or
just --debug=j you can get info on the return code the shell gives back
to make.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Make-w32 mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/make-w32
