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. _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
