Em Ter, 2006-06-20 às 15:57 -0700, Trent Piepho escreveu: > > Em Ter, 2006-06-20 s 12:23 -0300, Mauro Carvalho Chehab escreveu: > > > Since the old CVS days, the building system for V4L/DVB assumed that all > > > required kernel dependencies were compiled. This is bad, since some > > > obsoleted stuff might be required, without need (like, for example, OSS > > > support for saa7134_oss, cx88_oss that were replaced by saa7134_alsa and > > > cx88_alsa). > > > > > > With the inclusion of radio devices, some very unusual modules were also > > > required, to compile miropcm20 (the miro-pcm OSS mixer driver). > > > > > > The proposed patch adds the capability to the building system for it to > > > check kernel's config.h and autoconf.h at kernel building tree, > > You beat me too it. In fact some of the changes I've been making to the build > system have been aimed at this. There is still a bug with the config-compat.h > file that I was going to fix. I'm doing some fixes also at Makefile for it to work with 3.81, and I should post today. This will affect config-compat.h handler, since the kernel building system auto-generates several makefiles (like, for example, .flexcop-dma.o.cmd), doing some conflicts with config-compat.h rule. > > It looks like there is no way to get the old behavior? I think it is > important that there is still a way to build all modules, even if the current > kernel doesn't have ISA support or whatever. It makes it much harder for > developers to do proper testing without this. If you don't have all dependencies, building will just fail. Most claims we currently have about the building system are related to miropcm20. This piece needs miro oss mixer (SOUND_ACI_MIXER), that most people don't need. We had also to mark at compilation blacklist those modules like VINO that are used on non-intel architectures, and use arch-dependent calls. The alternative for the developers is to look at the dependency check messages and enable the proper modules at their kernels, like: VIDEO_M32R_AR: Required kernel opt 'M32R' is not present VIDEO_VINO: Required kernel opt 'I2C_ALGO_SGI' is not present VIDEO_M32R_AR_M64278: Required kernel opt 'VIDEO_M32R_AR' is not present VIDEO_M32R_AR_M64278: Required kernel opt 'PLAT_M32700UT' is not present So, for example, if I want Vino, I know that I need a SGI platform and enable I2C_ALGO_SGI. > > Is there a reason that you used the config.h and autoconf.h files? It seems > like it would be much easier to read the kernel's .config file. Since > autoconf.h is generated from .config, it's safe to require that .config be > there, isn't it? Can you even build v4l-dvb if it's not there? I know that > you will get non-fatal errors if $(KDIR)/.config is missing. Seems safer to trust at the headers, especially for those users that don't have kernel sources on their machines. It is not hard to read the .h files, and it also provides an additional info about tri-state dependencies. > > It looks like this can't handle all depend lines in v4l-dvb, for example: > depends on VIDEO_V4L2 && !SPARC32 && !SPARC64 > depends on VIDEO_DEV!=n > depends on RADIO_ZOLTRIX=y > depends on DVB_CORE && (PCI || USB) && I2C > > The '!' dependencies will be ignored (*). See bellow. > The '=' and '!=' are ignored. True. For the expressions we currently have, it will work fine, but for sure we should improve expressions handling to cover the entire syntax. > The bit '(PCI || USB)' will be treated as 'USB'. It will, in fact, require both PCI and USB. Also not really weird. > > (*) Not totally. They will be checked to see if they are not 'y' (**), but > they won't appear in Kconfig.kern like they should. > > (**) What does 'm' mean in this context? Does it means yes, no, or is the '!' > operator only allowed for booleans and not tristates? This is a weird behavior of Kbuild: if you negate a tri-state, Y becames N, but M remains as M, so ! is properly handled [1], since ! operator will do: 2-/expr/), and, as m=1, 2-1=1. [1] Documentation/kbuild/kconfig-language.txt Cheers, Mauro. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
