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

4 more lines

-----Original Message-----
From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
bounces at 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?

1 more quoted lines

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
[off-list ref] 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