From owner-cvs-all@FreeBSD.ORG Fri Apr 22 20:35:05 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E66A16A4CF; Fri, 22 Apr 2005 20:35:05 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 930D043D41; Fri, 22 Apr 2005 20:35:04 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j3MKcP6q013679; Fri, 22 Apr 2005 23:38:25 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 98501-13; Fri, 22 Apr 2005 23:34:42 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j3MKbtLc013649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2005 23:37:55 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3MKYbRX068689; Fri, 22 Apr 2005 23:34:37 +0300 (EEST) (envelope-from ru) Date: Fri, 22 Apr 2005 23:34:37 +0300 From: Ruslan Ermilov To: Marcel Moolenaar Message-ID: <20050422203437.GB50191@ip.net.ua> References: <20050422.114615.71130404.imp@bsdimp.com> <20050422175324.GA32739@ip.net.ua> <20050422184922.GA41457@ns1.xcllnt.net> <20050422.125712.78748765.imp@bsdimp.com> <20050422200341.GA23926@ip.net.ua> <1b042838f6396ae9665fcb2f41f1c9a7@xcllnt.net> <20050422201615.GD23926@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Warner Losh cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/config main.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 20:35:05 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2005 at 01:24:47PM -0700, Marcel Moolenaar wrote: > On Apr 22, 2005, at 1:16 PM, Ruslan Ermilov wrote: >=20 > >On Fri, Apr 22, 2005 at 01:08:14PM -0700, Marcel Moolenaar wrote: > >>On Apr 22, 2005, at 1:03 PM, Ruslan Ermilov wrote: > >> > >>>>>What exactly is broken? I don't see a breakage, even when source > >>>>>files disappeared. I assume I must be forgetting something or not > >>>>>doing everything right. > >>>> > >>>>when an include file is removed, make depend can fail to recreate > >>>>.depend in the modules. > >>>> > >>>This is only a problem with NO_CLEAN builds, and it's not limited > >>>to just modules -- I often saw this problem with the world builds. > >> > >>Ok. Does it help if there's an option to make that supresses the > >>automatic loading on .depend or more generically, allows one to > >>name the depend file and it merely defaults to .depend (suppression > >>is then accomplished by specifying /dev/null as the depend file)? > >>If such option would be used for "make depend", would that resolve > >>the problems in a generic way? > >> > >Nope. We only regenerate .depend when its dependencies are > >changed. For bsd.prog.mk, this means that .depend is only > >regenerated when some of ${SRCS} are changed (but this does > >NOT cover headers these ${SRCS} include, and some of these > >headers may disappear). > > > >To put it differently: when a header disappears, the breakage > >is not at the "make depend" stage (which doesn't do anything), > >but at a later "make all" stage. >=20 > I see. I'm probably not understanding the problem completely, > but this definitely gets me in the right state of mind. >=20 At point 1 in time, you have your source foo.c depend on header bar.h. At point 2 in time, bar.h disappears, source foo.c doesn't change (bar.h was depended through indirect inclusion via another header), and you try to rebuild. "make depend" won't rebuild .depend because foo.c didn't change, and "make all" will break because of a stale dependency recorded in .depend (foo.o: bar.h). I consider NO_CLEAN builds to be safe only when sources do not change, e.g., for incremental builds. At the very minimum, when sources change, .depend files should be regenerated. > >I personally fail to see how this can be solved... :-( >=20 > Ok, what about this: > mkdep(1) creates lines of the form >=20 > foo.o: foo.c inc1.h inc2.h >=20 > Would this problem be solved if mkdep(1) created lines like: >=20 > foo.o .depend: foo.c inc1.h inc2.h >=20 > or equivalent? >=20 > Would something else break if we do that? >=20 I fail to see what this gives us, except for also breaking "make .depend" when .depend is present and inc2.h disappears. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCaV/dqRfpzJluFF4RAqXnAKCKGlywgcddM3X8NXhWWWsdTAuBqgCggZYp Ssonecf7Oi/pFc3K2pKtRDY= =JYqs -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp--