want to verify equivalence of Kconfig variants
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? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies- bounces@kernelnewbies.org] On Behalf Of Robert P. J. Day Sent: Friday, February 24, 2012 11:41 AM To: Kernel Newbies Subject: want to verify equivalence of Kconfig variants
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?
rday
I'm no expert on kbuild, but I don't think your modification would be equivalent to what's there now. In Documentation/kbuild/makefiles.txt, they describe what obj-y means in section 3.2. If I follow the description, it defines objects that will be linked with the kernel image, so this: obj-y += displays/ presumably means that all source files in the displays subdirectory will be compiled and linked with the kernel image. With this: obj-$(CONFIG_OMAP2_DSS) += displays/ CONFIG_OMAP2_DSS could evaluate to 'm' depending on your configuration, which would mean the same objects would be linked into a loadable module. Jeff Haran
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
participants (3)
-
Dave Hylands -
Jeff Haran -
Robert P. J. Day