Em Qua, 2006-06-21 às 18:52 -0700, Trent Piepho escreveu: > On Wed, 21 Jun 2006, Mauro Carvalho Chehab wrote: > > > 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. > > The config-compat.h problem is still there. Unless you have more fixes for > this that aren't in Hg, I can fix this one. I did this fix on another test branch (just merging config-compat.h with .myconfig target), but I forgot to move this piece to the master. You can fix it if you want. > > > > 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 > > I can build the radio drivers, even though I have ISA turned off in my > kernel and they all need ISA. I could build and even use cx88-alsa, but > now it's turned off since I build the alsa driver devel tree out of > kernel, and have alsa turned off in the kernel. Currently, you have an option for this: using: make release DIR=/usr/src/linux-xxx This will force makefile to build against another kernel version, that may have different compiling options. This is very useful for backporting tests, for example. > > I think, there should options to do both: > > A. Make all modules my kernel, as configured, can use > B. Make all modules that my kernel can build > > B is what was done before, now you can o0Dnly get A. I think you will > find that drivers with extra dependencies on the kernel that most people > don't need will not get tested nearly so much. It would be nice if we can select the behaviors. Maybe we can add a "make allbroken" option that will force the building system to go to (B). > I have submitted many > fixes for drivers that I don't use. I suppose it would be better, if I > never did that? Of course your contributions were for good. > > > > 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. > > Is there a reason you don't just read autoconf.h, which doesn't have any > recursive includes to worry about? It has all the config options in it. > The structure of config.h is somewhat more complex, for example the you > will read in asm/kgdb.h because config.h includes it. We may use autoconf.h, but when this were introduced? using config.h will take some more milisseconds, but it seems to be safer, in terms of backportability. > > BTW, your config.h parser can't handle tabs. You'd be better served if you > used \S, non-whitespace character, in the regular expressions instead of > [^ ]. Also useful is \w, alphanumeric plus "_". There are options in the > kernel that use lowercase letters, which your code can't handle either. Ok, please send me a patch for it. > > > > 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. > > They don't work correctly. Look at the Kconfig.kern file, where is > SPARC32 and SPARC64? They don't appear in it at all. They should be > there, either on or off depending on the kernel. You have two totally > separate code paths that keep track of dependencies, one can handle '!' > and one can't. The one that can't is keeping them out of Kconfig.kern. argh! anyway, we need to properly handle the expressions. Can you also propose a patch for this? > > > > The bit '(PCI || USB)' will be treated as 'USB'. > > It will, in fact, require both PCI and USB. Also not really weird. > > No, that's not what happens. It will be totally ignored. If you don't > beleive me, and you should, I know perl pretty well, you can check for > yourself. Add this line to the config VIDEO_DEV in > linux/drivers/media/Kconfig: > depends on (SPARC32 || MADEUPCONFIG) > > VIDEO_DEV will still be turned on, even though both depenencies will fail. > Neither will be in Kconfig.kern either. It's not some unknown bug, I know > exactly what is wrong with the code. I was hoping that it could be fixed > before it was comitted. We had several complains with the building system, and, even with those fixes, now it is better to normal user than before. Please send me the proper fixes and I'll be happy to include it. Cheers, Mauro. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
