|From:||John N. Armstrong|
|Subject:||Warning messages not understood|
|Date:||Fri, 24 Nov 2000 12:24:44 -0600|
I’m not sure that this is a bug (in fact, I’m certain it’s not), but I can’t understand the behavior I’m getting from GNU make 3.79 running on an NT 4.0 SP6 system.
I have a “typical” recursive make file structure that I’m using to build a Java application. The top-level make invokes make in each of the sub-directories, which invoke make in their sub-directories, and so on. In every case, I’m invoking make using the “$(MAKE) –C <sub-directory> <target>” syntax. The makefile in each sub-directory includes a global makefile (by means of the include directive) with common variable definition and a default rule for making Java class files from Java source files.
Not surprisingly, all the makefiles are very similar in structure; for example, each makefile has a pseudo-target named, “clean:”.
As each makefile is processed, I get the following type of warning messages:
makefile:<line-no> warning: overriding commands for target ‘clean’
makefile:<line-no> warning: ignoring old commands for target ‘clean’
I receive a pair of these messages for each and every pseudo-target that happens to have the same name as a pseudo-target in a higher-level makefile.
I don’t understand this. I’ve not seen this behavior on other systems running GNU make (same release). I thought each invocation of make (i.e. for a sub-directory) was essentially independent of other (higher-level) invocations. However, these warning messages give me the impression that a common “rule space” is being used, and when make encounters a pseudo-target previously seen, its commands temporarily “overlay” any previous commands associated with that pseudo-target. This happens irrespective of whether I run make in UNIX mode (using the –unix command line option) or Win32 mode (using the –win32 command line option).
Other than the fact that I get lots of these warning messages each time I run make, everything appears to work OK – that is, the end result is correct.
I can find no information in the documentation as to why this happens, or how this behavior can be suppressed.
Can you enlighten me on what’s going on here?
John N. Armstrong, Sr. Partner
Armstrong, Sileven & Associates, L.L.P.
|[Prev in Thread]||Current Thread||[Next in Thread]|