Re: multiple prerequisites in pattern rules

[Paul D. Smith]

%% Noel Yap <address@hidden> writes:

  ny> Greg Chicares wrote:

  >> %.o: %.cpp
  >>        $(MAKEDEPEND)
  >>        $(CXX) -c $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $< -o$@
  >> 
  >> Would it be more 'transactional' to write the command thus?
  >> 
  >> $(MAKEDEPEND) && \
  >> $(CXX) -c $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $< -o$@

  ny> I believe so although I'm not 100% sure.

These are equivalent in all ways I can think of, with the possible
exception of one shell invocation more or less (without seeing exactly
what all the variables expand to I can't even tell you which one would
have more or less shell invocations).

  >> The former would execute in two subshells and the latter in one,
  >> but shouldn't make treat failure the same way in either case,
  >> absent a '-' command prefix or --keep-going?

  ny> I think this is supposed to be the way it works, but I'm not sure
  ny> if, in the first case, the second command cores, that the files
  ny> created by $(MAKEDEPEND) will be removed.

No matter what, if any command in the rule fails, the target(s) will be
removed (unless it's declared .PRECIOUS, IIRC).

No other files other than the target(s) will ever be removed (how could
they be, when make doesn't even know they were created?)

  >> Make passes commands to a shell, and knows only what the shell
  >> tells it about whether the commands succeeded, right?

  ny> Yes, this makes sense.  OTOH, exactly how does make check the exit
  ny> status of the subshell?

? Not sure what you mean.  Make invokes a process: it might be a
shell, it might be another command.  When the process ends, it provides
an exit value which make learns when it reaps the child process.  If
that exit value is 0, all is well.  If the exit value is !0, make
assumes the command failed.


In the discussion below I'm assuming you're talking about some kind of
POSIX/UNIX-type system.

  >> My occasional problem is that make passes
  >> $(CPP) $(CPPFLAGS) -M $< | $(SED) -e 'expression' > $*.d
  >> to the shell and $(CPP) does not terminate normally. More often,
  >> it's gcc that segfaults, and it prints an internal compiler error
  >> and terminates in an orderly fashion, returning an error code to
  >> make. But cpp doesn't seem to have that sort of error handling:
  >> when it fails...
  >> 
  >> - the build might just hang--probably with sed waiting for input
  >> that never comes

That can only happen if cpp hangs.  If cpp exits or dies in any way,
then the write side of the pipe will be closed and then sed will exit,
probably with some kind of read error.

  >> - the operating system might catch a segfault and pop up some
  >> messagebox, in which case I suppose it can tell make that the
  >> command failed--I rarely see this, so I'm not sure what happens

Pop up some messagebox?  I begin to suspect we aren't talking about UNIX
at all.

  >> - cpp might terminate early--flushing stdout but writing nothing
  >> to it, and returning a success code to the shell.

I think you're misinterpreting what happens here.

A pipeline is considered to be one long "shell command".  Each shell
command can have only exit code.  The exit code of a pipeline is
_ALWAYS_ the exit code of the LAST command in the pipeline.  If an
earlier command fails but the last command exits with success, then as
far as make can tell the command succeeded.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          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