[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiple prerequisites in pattern rules

From: Greg Chicares
Subject: Re: multiple prerequisites in pattern rules
Date: Fri, 30 Jan 2004 10:26:43 -0500

Noel Yap wrote:
> As for the SIG 11 that Greg Chicares mentioned, make actions
> should be transactional in that they should completely succeed
> or completely fail which means, at least for "complicated"
> actions, they need to be on one command line separated by '&&'

I'm doing this:

MAKEDEPEND = $(CPP) $(CPPFLAGS) -M $< | $(SED) -e 'expression' > $*.d

%.o: %.cpp
        $(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$@

I thought make stopped by default on the first failing command
in a rule, so that if a rule's commands are given as
that would have the same behavior with respect to failure as
        command0 && command1
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?

> (Paul may cite exceptions to this rule of thumb).  If it fails,
> IIRC, make will delete all generated files.

If you specify
which I routinely do.

> I'm not sure how
> it behaves if the action segfaults, though, but I would hope it
> treats these as failures as well; Paul, how does gmake behave
> under segfaulting actions?

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

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

 - 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

 - cpp might terminate early--flushing stdout but writing nothing
   to it, and returning a success code to the shell. Hardware
   problems make anything possible. If cpp owns some memory
   location that stores the number of bytes left to process and
   that location gets zeroed, then neither the OS nor the shell
   can detect that, so neither can make. I speculate that this is
   the most common occurrence here, because I often get zero-byte
   .d files.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]