[Kai Germaschewski] > I've been thinking about doing something like this a couple of > times. The reasons I didn't actually do it yet was that include > $(TOPDIR)/Rules.make was kind of a separator between automatically > handled stuff and additional hand-made rules for special cases.
Well, OK - but I don't see why you have to separate the two sections in the common case where there *isn't* a second section. Mainly I was thinking that this patch was a *really* easy way to lose a *lot* of lines. The most dramatic change would have to be arch/ia64/pci/Makefile, which goes from 3 lines down to 1. (: I suppose getting rid of 'include Rules.make' in *all* cases is better, but of course it would also be a lot more intrusive. > This distinction becomes a little more obvious with separate > src/objdir or another patch I'm about to send, i.e. not really > descending during the recursive make. Hmm. It seems to me that if you're going to keep the recursive make, you should continue to descend into $(obj). This simplifies hand-made rules, as they would never have to mention $(obj) specifically. > to avoid confusion where these prefixes are necessary and where it's > not, the split is kinda helpful, I think. With proper VPATH support, basically the only place you ever have to mention $(src) is in the shell code for rules. And, as I said above, you should *never* have to think about $(obj) - it should just always be the current directory. > Anyway, I think it's sth definitely worth considering, but if we do > it, we should do so completely. AFAICS, there's two reasons why > Rules.make is included in the middle. Of course it needs to be > included after the obj-[ymn] and friends are set to do something > sensible. It defines $(obj), $(src), so it needs to be included > before those are used Easy to work around, as you demonstrate below. > and it currently relies on Rules.make's first_rule really being the > first rule in a Makefile. I don't see the importance of first_rule being the first rule. Isn't that pretty well controlled from $(TOPDIR)/Makefile? > So one could actually do > > make -f Rules.make obj=subdir src=subdir > > and Rules.make contains: > > include .config > > include $(src)/Makefile > > [rest of Rules.make follows here] I like it. > > As a positive side effect, we can now get rid of the $(MAKEFILES) > > kludge. (Hi Michael!) As a negative side effect, we prevent GNU > > make from being clever and recursing on 'make -n'. > > Well, I didn't find MAKEFILES a particularly bad hack, it's > basically using MAKEFILES the way it's supposed to be used. It's pretty harmless, but is still a hack. An explicit 'include .config' is a lot more obvious if you don't already know the purpose of the construct. > I don't think the make -n thing hurts (I'm breaking that with my > other changes, too). Good - I agree. I just felt obliged to mention it since some people might care about it. Peter ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
