From: Keith Owens <kaos@ocs.com.au>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>, linux-kernel@vger.kernel.org
Subject: Re: crc32 cleanups
Date: Sat, 13 Oct 2001 11:51:17 +1000 [thread overview]
Message-ID: <14801.1002937877@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Fri, 12 Oct 2001 14:37:52 EST." <Pine.LNX.3.96.1011012143222.6594D-100000@mandrakesoft.mandrakesoft.com>
On Fri, 12 Oct 2001 14:37:52 -0500 (CDT),
Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
>(linux/lib/Makefile)
>obj-$(CONFIG_TULIP) += crc32.o
>obj-$(CONFIG_NATSEMI) += crc32.o
>obj-$(CONFIG_DMFE) += crc32.o
>obj-$(CONFIG_ANOTHERDRIVER) += crc32.o
It is better to define CONFIG_CRC32 and have the Config.in files set
CONFIG_CRC32 for selected drivers. That avoids the problem of lots of
drivers wanting to patch the same Makefile, instead the selection of
crc32 is kept with the driver selection.
lib/Makefile
obj-$(CONFIG_CRC32) += crc32.o
drivers/foo/Config.in
if [ "$CONFIG_FOO" = "y" ]; then
define_bool CONFIG_CRC32 y
fi
It is even cleaner in CML2.
require FOO implies CRC32=y
In general it is a bad idea to handle selections in the Makefile, that
is what CML is for. Makefiles should just build the code based on CML
output, not try to decide what to build.
next prev parent reply other threads:[~2001-10-13 1:51 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-12 19:11 crc32 cleanups Matt Domsch
2001-10-12 19:25 ` Jeff Garzik
2001-10-12 19:37 ` Jeff Garzik
2001-10-13 1:51 ` Keith Owens [this message]
2001-10-13 2:36 ` Jeff Garzik
2001-10-13 2:45 ` Keith Owens
2001-10-13 2:56 ` Jeff Garzik
2001-10-13 3:12 ` Keith Owens
2001-10-12 19:45 ` Horst von Brand
2001-10-12 20:07 ` Jeff Garzik
2001-10-13 1:04 ` Horst von Brand
2001-10-13 1:09 ` Jeff Garzik
2001-10-13 12:45 ` Horst von Brand
2001-10-13 9:48 ` Jan-Marek Glogowski
2001-10-13 10:02 ` Andi Kleen
2001-10-13 10:07 ` Jan-Marek Glogowski
2001-10-13 23:09 ` Horst von Brand
2001-10-13 10:25 ` Keith Owens
2001-10-15 8:29 ` Bjorn Wesen
2001-10-15 11:35 ` Keith Owens
-- strict thread matches above, loose matches on Subject: below --
2001-10-12 20:17 Matt_Domsch
2001-10-12 20:34 ` Jeff Garzik
2001-10-13 1:20 ` Horst von Brand
2001-10-13 15:16 ` Martin Dalecki
2001-10-13 1:09 ` Horst von Brand
2001-10-13 1:20 ` Jeff Garzik
2001-10-12 22:20 Matt_Domsch
2001-10-12 22:34 ` Jeff Garzik
2001-10-13 2:09 Stuart Lynne
2001-10-13 3:46 Matt_Domsch
2001-10-13 11:47 ` Kai Henningsen
2001-10-14 3:19 Matt_Domsch
2001-10-15 11:34 Samium Gromoff
2001-10-16 19:05 Matt_Domsch
2001-10-23 21:19 Matt_Domsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14801.1002937877@ocs3.intra.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=Matt_Domsch@dell.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox