On Wed, 2 Oct 2002, Peter Samuelson wrote:

> Almost all kernel makefiles have to include $(TOPDIR)/Rules.make
> explicitly.  3/4 of the time, this is done at the end of the file.
> This patch lets you omit the include line in that case.  (You still to
> include Rules.make explicitly if you have special make rules.)

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.

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. If you pass what you want to be done in variables to
Rules.make, you have a chance to manipulate this vars, e.g. adding proper
src / obj paths. However, if you explicitly write a rule into a Makefile,
Rules.make has no way to fix up paths or anything. That's why for the
latter, you have to use $(src) / $(obj) explicitly, and to avoid confusion
where these prefixes are necessary and where it's not, the split is kinda
helpful, I think.

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, and it currently 
relies on Rules.make's first_rule really being the first rule in a 
Makefile.

Both the $(obj)/$(src) and the first_rule restriction could be lifted, 
making it possible to have Rules.make come last, AFAICS.

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]

Sounds worth trying?

Anyway, I have still two other changes lined up, the "do everything from 
the topdir" one and Sam's "make clean" work. Once that is in (RSN, I 
hope), why not see if the above works out.

> 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.

I don't think the make -n thing hurts (I'm breaking that with my other 
changes, too). If anybody gives good reasons why we should keep it,
it's just a matter of a little more typing to get it back to working, 
anyway.

--Kai




-------------------------------------------------------
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

Reply via email to