Try #3 at the .7 implicit rule problem

[Nathanael Nerode]

Kelley Cook wrote:
>  >>GNU Make always uses the rule itself when determining $<.  If you use
>  >>$+, you do get all of the dependencies -- but the ones not in the rule
>  >>itself come after the ones in the rule.
>  >
>  > Indeed, I just verified this.  :-)
>  >
>  > However, note that Kelley's proposed patch contains *no* dependencies
>  > in the rules themselves, and *does* therefore generate difficult order
>  > dependencies.
> 
> ... one day later after pouring through the Make manual and doing lots 
> of experimenting ...
> 
> First of all, as Mark alluded to, addtional dependencies are appended to 
> the rule being executed.  Therefore, in the case of implicit rules a $< 
> will either refer to the first dependency listed on the implicit rule or 
> to the first dependency on the command-less specific rule that caused 
> the implicit rule to be run.
And if there are multiple command-less specific rules?  It'll grab the 
first one.  Even if

> 
> The manual does mention that an implicit rule is allowed to be without 
> dependencies.  This, of course, means that the implicit rule will fire 
> every time it matches the pattern of a target that make has determined 
> needs to be built.
> 
> This could lead to problems in a specific instance, when the dependency 
> were never specified at all for a specific target.
Different problem.

> Would this version be OK to install?

Not quite, cause it still doesn't fix or document the potential future 
order dependency problem.  :-)  Sorry.  See below.

> +# The *.1, *.7, *.info, and *.dvi files are being generated from implicit 
> +# patterns without any dependencies.  Therefore, it is required that all 
> +# of these targets have themselves listed with their specific dependencies.
> +# In addition please list the input file first in the dependency list, 
> +# since the implicit patterns are using $< for the input file.

You could add:
   +# In addition, if you add other dependency lines for these files, you
   +# must make absolutely sure that the line listing the primary file
   +# comes first in the Makefile, again because the implicit patterns
   +# are using $<.

However, this is annoying and stupid.  It's better to have the primary 
dependency on the rule line so that other dependencies don't have to 
worry about where they are in the Makefile.

To try to point out the problem again, suppose this was added earlier in 
the Makefile:
INFO_NEEDING_SUPPORT = $(docobjdir)/cpp.info $(docobjdir)/gcc.info
$(INFO_NEEDING_SUPPORT): special-info-support.xxx

 > -$(docobjdir)/%.info: $(docdir)/%.texi stmp-docobjdir
 > +$(docobjdir)/cpp.info cpp.dvi: $(TEXI_CPP_FILES) stmp-docobjdir
 > +$(docobjdir)/gcc.info gcc.dvi: $(TEXI_GCC_FILES) stmp-docobjdir
 > +$(docobjdir)/gccint.info gccint.dvi: $(TEXI_GCCINT_FILES) stmp-docobjdir
 > +$(docobjdir)/gccinstall.info gccinstall.dvi: $(TEXI_GCCINSTALL_FILES) \
 > +	 stmp-docobjdir
 > +$(docobjdir)/cppinternals.info cppinternals.dvi: $(TEXI_CPPINT_FILES) \
 > +	 stmp-docobjdir
 > +
 > +$(docobjdir)/%.info:
 > +	$(if $<,,$(error $@ requires a dependency to be defined.))
 >  	if [ x$(BUILD_INFO) = xinfo ]; then \
 >  		$(MAKEINFO) $(MAKEINFOFLAGS) -I $(docdir) \
 >  			-I $(docdir)/include -o $@ $<; \
 >  	fi

Guess what would become the 'first' file?  Yep, special-info-support.xxx 
would.  Yes, I tested this type of arrangement.

If it is deemed greatly, greatly preferable not to put dependencies in 
the implicit patterns, add the comment.

Otherwise, please rename most of the files that don't work with the 
natural %.info: $.texi dependencies, and deal with the need for one 
extra rule for gcc.info.  I realize the renames are a bit of work but I 
bet you can do it.  :-)

...
>  generated-manpages:: $(docobjdir)/gcov.1 $(docobjdir)/cpp.1 \
>  	$(docobjdir)/gcc.1 $(docobjdir)/gfdl.7 $(docobjdir)/gpl.7 \
>  	$(docobjdir)/fsf-funding.7

I know this is none of your doing, but who put double-colon rules in 
here, and why?  They're nice when they're appropriate, but I don't see 
that they're appropriate.