want to verify equivalence of Kconfig variants

[Dave Hylands]

Hi Robert,

On Fri, Feb 24, 2012 at 11:40 AM, Robert P. J. Day
<rpjday at 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