Hi Robert, On Fri, Feb 24, 2012 at 11:40 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
i'm fairly sure i know the answer to this, but i figured i'd run it by others just to make sure i'm not missing anything subtle.
in drivers/video/omap2/Makefile, we see:
... snip ... obj-$(CONFIG_OMAP2_DSS) += dss/ obj-$(CONFIG_FB_OMAP2) += omapfb/ obj-y += displays/ ... snip ...
and when i see "obj-y", i like to assume that's a component that will be compiled unconditionally. but if you look at the Kconfig file in the displays/ directory, you see:
menu "OMAP2/3 Display Device Drivers" depends on OMAP2_DSS ... entire file contents ... endmenu
but that suggests that that entire subdirectory depends on OMAP2_DSS, so one could remove the dependency from that Kconfig file and just move it up to the Makefile above:
obj-$(CONFIG_OMAP2_DSS) += displays/
correct? i prefer that approach since the dependency is obvious from the Makefile, without having to descend into the directory itself to learn of it.
thoughts? is there anything i'm not noticing about this?
There is one subtle difference. 1 - Configure such that CONFIG_OMAP2_DSS is set and do a build 2 - Configure such that CONFIG_OMAP2_DSS is not set and do a clean When obj-y += displays is used, the clean will clean out the displays directory When obj-$(CONFIG_OMAP2_DSS) is used, then the clean won't clean out the displays directory, and I think you can wind up with the unclean built-in.o being compiled into your kernel, but I'm not 100% on that. As long as you did the clean before changing the config, you'd not see any difference. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com