Re: multiple prerequisites in pattern rules

[Noel Yap]

Greg Chicares wrote:
> 
> 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
>         $(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$@

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

> I thought make stopped by default on the first failing command
> in a rule, so that if a rule's commands are given as
>         command0
>         command1
> 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?

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

> > 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?

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

> 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.

Interesting.  I've seen zero-byte .d files from time to time, but I've never 
tracked down the cause.

I think even the traditional way of generating .d files would have these 
problems.  I'm not sure what can be done about them other than fixing cpp and 
gcc.

Noel
-- 
NOTICE: If received in error, please destroy and notify sender.  Sender does 
not waive confidentiality or privilege, and use is prohibited.