Date: Tue, 4 Apr 95 16:46:58 MDT From: terry@cs.weber.edu (Terry Lambert) To: kargl@troutmask.apl.washington.edu (Steven G Kargl) Cc: nate@trout.sri.MT.net, freebsd-hackers@freefall.cdrom.com Subject: Re: new install(1) utility Message-ID: <9504042246.AA20745@cs.weber.edu> In-Reply-To: <199504042108.OAA05566@troutmask.apl.washington.edu> from "Steven G Kargl" at Apr 4, 95 02:08:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The problem is improper dependency graphs in the makefile. > > > > And jamming make-like dependency capability into install is a > > cockamamy way to fix it. [ ... ] > I usually understand about 50% of your postings, but I must really be > missing the boat here. How can the creation of an intermediate > (temporary) directory, a chown operation on the directory, installation > of the file(s) to the intermediate directory, finally installing the > file(s) from the intermediate directory to their ultimate destination, > and deleting the temporary directory improve the performance of install? The problem is the need for a .h/installed .h rule. in other words: /usr/include/foo.h: foo.h cp -p foo.h $@ or something similar for each include file in the /usr/src/include makefile. The compare in this case is on the data of the src and target, which is perfectly sufficient to only do the copy in case of a change. If the argument is that a change could occur without a date change, that argument holds true for .o:.c dependencies and program:*.o dependencies as well. Either you are going to keep the date accurately for all things or you can't trust any date. > I believe Nate (and I) is trying to avoid the (unnecessary) installation > procedure if the target file already exists and the source and target > are the same. And dates and dependencies are considered insufficient to resolve this problem? I don't believe it. I really don't see why the creation of an intermediate directory, chown operations, or use of the install command for an install target (just because it happens to be named the same, I suppose) is really necessary for include files. Why is this being built up to be so hard? The only issue I see regarding headers is subverting the default include (and library) path for a cross-compilation environment. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504042246.AA20745>