On Mon, 9 Feb 2009 16:48:27 -0800 (PST) Trent Piepho <xyzzy@xxxxxxxxxxxxx> wrote: > On Mon, 9 Feb 2009, Mauro Carvalho Chehab wrote: > > On Thu, 5 Feb 2009 10:57:21 -0800 (PST) > > Trent Piepho <xyzzy@xxxxxxxxxxxxx> wrote: > > > 01/03: cx88: Fix MPEG kconfig dependencies > > > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=2e05fd69e6b6 > > > > Hmm... This patch converts a depends on into a select. This is not nice, since > > select is known to not be properly handled by kernel build system. Also, the > > kbuild maintainer recommended us to use select only for options that doesn't > > have any dependency. > > This is reflected on Kbuild docs: > > > > Note: select should be used with care. select will force a symbol to a value > > without visiting the dependencies. By abusing select you are able to select a > > symbol FOO even if FOO depends on BAR that is not set. In general use select > > I'm aware of the problem with select. One way to deal with is to have > whatever is selecting FOO also depend on BAR. In this case CX88_MPEG only > has one dependency, VIDEO_CX88. Both CX88_BLACKBIRD and CX88_DVB already > depend on VIDEO_CX88 so there is no problem. Since CX88_MPEG is a hidden > option and it's highly unlikely it will gain a dependency that > CX88_BLACKBIRD and CX88_DVB do not also also have, I think this use of > select is not so bad. I took some time during this kernel cycle trying to fix mpeg dependencies. One issue that I had to deal with is that some possible configurations with CX88, CX88_BLACKBIRD and CX88_DVB causes breakages (weird configs like having one as M and others as Y). Those weird configurations don't have any practical usage, but causes lot of headaches at the Kconfig logic. I suspect that the current way compiles fine in-kernel, but maybe the out-of-tree logic may have some troubles on handling it (at least, Ingo and others that likes to play with all possible configurations didn't complain yet with the current cx88 Kbuild). > > So, IMO, we should solve the issue using a different logic that relies only on > > depends on. > > This can be done, it was the other option I mentioned. MPEG needs to be > made a visible option, which BLACKBIRD and DVB will then depend on instead > of selecting. I didn't do this because of complaints about kernel > configuration getting too complex with too many options. So I didn't think > a patch exposing another option would be better. > > It would look something like this: > > config VIDEO_CX88_MPEG > tristate "MPEG and digital TV interface" > depends on VIDEO_CX88 > help > Support for the "MPEG port" on Conexant CX2388x chips, which shows up > as function 2 of the PCI device. This is used by DVB/ATSC digital TV > cards as well as cards with the Conexant "Blackbird" CX23416 MPEG > encoder. > > config VIDEO_CX88_MPEG I'm assuming CX88_DVB here. > tristate "DVB/ATSC Support for cx2388x based TV cards" > depends on VIDEO_CX88_MPEG > ... > > config VIDEO_CX88_BLACKBIRD > tristate "Blackbird MPEG encoder support (cx2388x + cx23416)" > depends on VIDEO_CX88_MPEG > ... > > Would that be better? No select, but there is another option for the user to > pick when configuring their cards. I almost used a similar logic like above (just replacing tristate by boolean on CX88_DVB and CX88_BLACKBIRD to avoid the weird and unpractical kconfigs). I agree that adding more questions to the poor end-user is evil. So, I decided for a hidden var for CX88_MPEG, than adding a meaningless option (on the user POV), on the latest CX88 Kbuild changeset. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
