[Adding bug-gnulib to this thread. For bug-gnulib readers, the scenario is in Emacs a "bzr update; make" failed with:
./unistd.h:1186:5: error: token "@" is not valid in preprocessor expressions because unistd.h was built with the old Makefile. Full thread at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8675#31>. ] On 05/18/11 05:39, Andreas Schwab wrote: > If that does not work, then proper dependencies are missing. I don't see how adding a dependency would fix this problem. In this case, lib/Makefile in turn depended on 'configure', 'configure.in', 'm4/longlong.m4', etc., etc., and one of these files got updated, so lib/Makefile was regenerated; but as I understand it, the 'make' that was (still) running was based on the out-of-date lib/Makefile, and it generated the a bad lib/unistd.h. Adding a dependency "unistd.h: Makefile" wouldn't fix this problem. This sort of problem is not due to gnulib per se; it's inherent to any project that uses makefiles. In general, if a patch modifies a makefile, or anything the makefile depends on, then you must regenerate everything from scratch with a fresh 'make' invocation. That being said, I've run into Christoph's problem myself more than once, and it's a hassle, and it'd be nice to address it somehow. How about this idea? I expect it would have worked around this problem. Currently lib/Makefile contains something like this: unistd.h: <dependencies> <big-hairy-command> Suppose we change this rule to look like this: unistd.h: Makefile <dependencies> case ' $? ,$(USING_NEW_MAKEFILE)' in \ *' Makefile '*,) \ exec $(MAKE) $(AM_MAKEFLAGS) USING_NEW_MAKEFILE=yes $@;; \ esac; \ <big-hairy-command> This would be a gnulib change, so I'll CC: this to bug-gnulib. A similar pattern would apply to every module that generates a .h file with a big hairy command that uses 'make' variables.
