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.
> > 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.
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. I have submitted many
fixes for drivers that I don't use. I suppose it would be better, if I
never did that?
> > 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.
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.
> > 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.
> > 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.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
