On Fri, Oct 26, 2007 at 09:33:20PM +0200, Vegard Nossum wrote:
> Ah, I see now that the same syntax is used in other places too.
>
> Thank you. I am trying to make the non-recursive makefile and I hit
> this issue: Since all the makefiles are included into the top-level
> makefile, such variables as pci-y are left "hanging around" into other
> makefiles if the top-level makefile does not know that the variable
> was defined.
>
> So my problem was that drivers/pci/Makefile sees "pci.o" as a
> composite object and tries to make it depend on arch/x86/pci/fixup.o,
> which is of course completely wrong!
>
> But if arch/x86/pci/Makefile had used pci.o instead of $(pci-y), then
> my makefile would detect that pci.o was a composite object and clean
> up the pci-* variables after they had been used.
>
> Is there a problem with my changing that $(pci-y) to pci.o? I mean,
> will it change the logic of the makefile? I can't really see any other
> way to undefine variables introduced by included makefiles than to
> notice that they are part of composite objects, and then clean up the
> parts after the composite has been built. But I realize that this is
> rather fragile. There are more issues than just that. Because a
> composite may (legally) still not be referenced by any variable that
> will be used... Hmm :-/
The simple (but not safe and friendly) solution would be to require
users to clean up after them. So in this case to set:
pci-y :=
Try to do that for now and see how far you get.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
