This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: More Makefile cleanups


> > > + $(genprogs:%=%$(buildextext)): \
> > 
> > I believe this is the type of textual obfuscation that we were worried
> > about ;-)
> 
> I'm slightly confused by your and Nathanael's comments on this patch.

I'm going to generically agree with Nathanael about syntax and debugging,
and add my own generalizations:

	No non-trivial macros on rule lines.

	All colons in rules should be on the same line.

Trivial would be $(FOO_FILES) or foo$(EXEEXT), but nothing else.  The
colon rule also helps with grepping.

Additionally:

	Any macros defined specifically for one rule must immediately
	precede that rule.

Macros defined for generic use can be listed at the beginning like we
do now.

> Why is it better to have multiple sets of dependencies?  By including
> them in the static pattern rule, there are fewer places to look to see
> what the dependencies are.

If all the targets have exactly the same dependency list, I'd be OK
with listing it in the pattern rule and omitting the separate rules.
However, if there's going to be separate dependency rules anyway, IMHO
it would be more coherent to put all the dependencies in separate
rules.

I think the general rule here is that it should be obvious where the
dependencies (or macros, or targets, or in general anything in the
Makefile) are, without the likelyhood of being fooled into a false
belief that what you've found is all there is.

If you had most of the dependencies in the pattern rule, and listed a
few more specific ones elsewhere, the user might not thing to look for
the extra ones, and be confused when it doesn't do what's expected.
I'd like to avoid confusion ;-)

This also precludes the "foo += bar" macro lines, although I'd be OK
with macros that exist *only* to be used that way, providing they're
commented as such in the main Makefile and aren't otherwise on the
left side of the equals sign (except, perhaps, to empty them at the
beginning of the main Makefile, which is where the comment should go
too).  I.e. (note lang_grills named in comment for grepping):

	# lang_grills is +='d from foo fragments
	lang_grills = 

	(later, in lang/foo.frag)
	lang_grills += foo_bar1 foo_bar2


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]