From owner-cvs-all Wed Feb 28 4:35:31 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1429537B718; Wed, 28 Feb 2001 04:35:24 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA19611; Wed, 28 Feb 2001 23:35:20 +1100 Date: Wed, 28 Feb 2001 23:35:12 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Doug Rabson , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Peter Wemm Subject: Re: cvs commit: src/sys/conf kmod.mk In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Feb 2001, John Baldwin wrote: > On 27-Feb-01 Doug Rabson wrote: > > On Mon, 26 Feb 2001, Peter Wemm wrote: > > > >> peter 2001/02/26 17:23:34 PST > >> > >> Modified files: > >> sys/conf kmod.mk > >> Log: > >> Add pci/agp_if.m to the MFILES list so that we can auto depend on agp_if.h > > > > I wish I could think of a way to avoid listing all the .m files in MFILES. > > This is just so we can build kernels w/o a make depend, yes? Er, no. It is so that module Makefiles don't have to know where the .m files are. See modules/agp/Makefile. It still knows where agp_if.m is, and even knows where other .m files are. There seems to be a problem in the setting of MFILES. kmod.mk uses "MFILES?=", so indivual Makefiles can't modify the default MFILES; they have to repeat everything. Otherwise, knowing where agp_if.m is in agp/Makefile would be reasonable -- only agp uses it. Listing all the .m files in MFILES is not really different from listing all kernel source files in /sys/conf/files in /sys/conf/files*. The problem is that the lists are duplicated. The duplication is worst for .h files. Some options headers must be duplicated in many module Makefiles, but config(8) generates them automatically for kernels. Peter's changes to make building modules more like building the kernel will presumably have the side effect of fixing this. I'm not sure how they would avoid building zillions of options headers when you just want to build a small module. The information about which .c files depend on which options headers is not available until `make depend' has looked at all the source files, and this takes too long. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message