From owner-cvs-src@FreeBSD.ORG Sat Apr 23 06:19:50 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB9C16A4CE; Sat, 23 Apr 2005 06:19:50 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF73843D2D; Sat, 23 Apr 2005 06:19:49 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3N6Hnls044881; Fri, 22 Apr 2005 23:17:49 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050423050234.GB10314@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> <20050422203437.GB50191@ip.net.ua> <94969eabff134918730e7dcead17bb51@xcllnt.net> <20050423050234.GB10314@ip.net.ua> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 22 Apr 2005 23:17:49 -0700 To: Ruslan Ermilov X-Mailer: Apple Mail (2.622) 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 06:19:50 -0000 On Apr 22, 2005, at 10:02 PM, Ruslan Ermilov wrote: > On Fri, Apr 22, 2005 at 01:58:34PM -0700, Marcel Moolenaar wrote: >> On Apr 22, 2005, at 1:34 PM, Ruslan Ermilov wrote: >> >>>>> I personally fail to see how this can be solved... :-( >>>> >>>> Ok, what about this: >>>> mkdep(1) creates lines of the form >>>> >>>> foo.o: foo.c inc1.h inc2.h >>>> >>>> Would this problem be solved if mkdep(1) created lines like: >>>> >>>> foo.o .depend: foo.c inc1.h inc2.h >>>> >>>> or equivalent? >>>> >>>> Would something else break if we do that? >>>> >>> I fail to see what this gives us, except for also breaking >>> "make .depend" when .depend is present and inc2.h disappears. >> >> True, there is a phase ordering problem. But isn't that something >> that can be worked around by making the necessary adjustments to >> make(1). The adjustments would be that if .depend is out of >> date, it is being made without making any sources that are out >> of date (or missing). This may require adding a special source >> to the mix of special sources that make(1) already has: .SOFTDEP >> or something like that. One can also hardcode this special case, >> but that seems ugly. >> > That's an idea! I've tested the following, and it seems that it > can be made to work, after some polishing. In .depend, have the > following dependencies generated by mkdep(1): > > .depend: > .for f in > .if !exists($f) > $f: > .endif > .endfor Another idea -- same end result: What about having make(1) handle it all by itself, with only the help of being told which extensions can affect .depend. Since make(1) has the complete dependency graph, it shouldn't be too hard for it to traverse the graph, determine whether .depend is out of date WRT to all the files with the given extension in the dependency graph and rebuild the .depend target (if one is defined) automagically. In the end, the whole .depend inclusion is hardcoded and one can argue that make(1) should make sure this auto- feature is not getting in the way. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net