Date: Tue, 4 Apr 1995 17:17:53 -0600 From: Nate Williams <nate@trout.sri.MT.net> To: julian@tfs.com (Julian Elischer) Cc: terry@cs.weber.edu, kargl@troutmask.apl.washington.edu, freebsd-hackers@freefall.cdrom.com Subject: Re: new install(1) utility Message-ID: <199504042317.RAA07928@trout.sri.MT.net> In-Reply-To: julian@TFS.COM (Julian Elischer) "Re: new install(1) utility" (Apr 4, 3:55pm)
next in thread | raw e-mail | index | archive | help
[ Modifying install to be 'smarter' about installing files ] > but if the Makefiles didn't see a reason to update it, then it would > be untouched and the same thing would result. Agreed. We'd need to modify the 'install' target in the .mk files to do the right thing. This is one solution to the problem, but IMHO modifying install would make it go faster, and it still follows the unix tradition of making the tool do one thing very well. Making install smarter about installint is not going against that tradition. > what we want is a make rule for X/a -> B/a > (i.e. just moving a file) Install can do that now, but then the file has to be re-generated in the source tree which causes the dates to change, which requires a comparison if it's to be installed again and we're at the same point we were before. > not to mention the trouble we have at the moment with > man pages and that #$%^# gzip.. Stolen from email Steven sent to me: if ( source.size != target.size || cksum.source != cksum.target ) Install the new one. else /* They're the same, don't bother screwing with the timestamp */ We get the added benefit of literally no overhead for the case when the sizes don't match, and the requirement of the two cksums if they do match. My guess is the two cksums are faster than the 'cmp' step used in some of the makefiles. And, if we pre-build the compressed man-pages, we can do the comparisons at install time to determine if they need to be installed or not. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504042317.RAA07928>