> What I did propose was to eliminate the Config.in special casings all
> over the place to turn this stuff on. It's just a wart when I look at
> it. But you don't seem to like that idea so I'll drop it.
I'd like to eliminate lots of the magic weird cases in Config.in too - but
by making the language express it. Something like
tristate_orif "blah" CONFIG_FOO $CONFIG_SMALL
From: Alan Cox <[email protected]>
Date: Fri, 1 Feb 2002 00:42:44 +0000 (GMT)
I'd like to eliminate lots of the magic weird cases in Config.in too - but
by making the language express it. Something like
tristate_orif "blah" CONFIG_FOO $CONFIG_SMALL
This doesn't solve the CRC32 case. What if you want
CONFIG_SMALL, yet some net driver that needs the crc32
routines?
On Thu, Jan 31, 2002 at 08:25:09PM -0800, David S. Miller wrote:
> From: Jeff Garzik <[email protected]>
> Date: Thu, 31 Jan 2002 22:46:35 -0500
>
> Maybe not in this hypothetical future situation, but currently makefile
> magic was added for crc32 specifically to ensure that it is linked
> in when needed... even when CONFIG_CRC32=n.
>
> The Config.in for crc32 only exists for the case where no driver in the
> built kernel uses it... but a 3rd party module might want it.
>
> My point is this: Having to say something like "CONFIG_INEED_CRC32"
> for each driver that needs it is just plain stupid and a total eye
> sore.
I agree.
This is -not- the situation now, and it will never be the situation.
Did you read drivers/net/Makefile.lib ?
Another example, take a look at drivers/video/Config.in. We actually do
not need those hideously long if statements "if foofb or barfb or bazfb"...
Makefile rules clean that shit up nicely.
> It would be really great if, some day, you just add your source
> file(s) to drivers/net and that is the only thing you ever touch. You
> DO NOT touch Makefiles, you DO NOT touch Config.in files, you DO NOT
> add Config.help entries.
You are preaching to the choir. ;-)
> The Makefile rules are auto-generated from keys in the *.c file(s), as
> are the Config.in and help entries. Ie. cp driver.[ch]
> linux/drivers/net and then simply rebuild the tree.
Close... Check out this thread from December. I agree with Linus
we need metadata files (driver.conf), not yanking all that info out
of the source code.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.3/0969.html
and
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.3/0801.html
To sum, Makefile rules are better than Config.in garbage because it can
be far more modular, and more resistant to breakage. But, for the
longer term, we want 8139too.conf and lance.conf and...
Regards,
Jeff
From: Jeff Garzik <[email protected]>
Date: Thu, 31 Jan 2002 23:48:45 -0500
I agree with Linus we need metadata files (driver.conf), not
yanking all that info out of the source code.
I'm perfectly fine with this too.
> tristate_orif "blah" CONFIG_FOO $CONFIG_SMALL
>
> This doesn't solve the CRC32 case. What if you want
> CONFIG_SMALL, yet some net driver that needs the crc32
> routines?
The crc32 dependancy deduction is a seperate problem to asking excessive
questions. That is down to the makefiles. If its hard to express then
presumably Rules.make isnt yet perfect.
Does kbuild make it all simpler ?