Date: Tue, 4 Apr 95 17:03:00 MDT From: terry@cs.weber.edu (Terry Lambert) To: nate@trout.sri.MT.net (Nate Williams) Cc: kargl@troutmask.apl.washington.edu, freebsd-hackers@freefall.cdrom.com Subject: Re: new install(1) utility Message-ID: <9504042303.AA21054@cs.weber.edu> In-Reply-To: <199504042123.PAA07372@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 03:23:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The problem is improper dependency graphs in the makefile. > > Huh? Methink you don't understand the problem Mr. Lambert. > > trout:/usr/user/nate % ls -l /usr/include/stdio.h > -r--r--r-- 1 bin bin 12938 Nov 22 04:38 /usr/include/stdio.h > trout:/usr/user/nate % > > Now, if I got into /usr/src/include and do a 'make install' > the date of that file will change due to the install copying the file in > /usr/include over top of the old file, even though they are the same file > in all respects. Serves you right for using the install utility to do the install instead of using "cp -p". The problem in this particular example is using an otherwise overpowered piece of software to try to do something it can't doe effectively. > > And jamming make-like dependency capability into install is a > > cockamamy way to fix it. > > It has nothing to do with make-like dependency capabilities. With the > addition of that option, install now determines if it really needs to > install the files rather than blindly doing it no matter what. A dependency would keep install from being called at all unless the target were younger than the source. Still better is to use "cp -p" to preserve the source date when copying to the target instead of using the install program at all for this particular "install:" target. > > Much better (if one must hack on install) to cause intermediately > > created directories when installing a target to be owned by the > > specified user and group instead of being owned by the installer > > (hint: this would fix a number of X install problems). > > This is orthogonal to the entire discussion, and why you are bringing it > up is beyond me. Have you been talking with J. Monroy lately? Hacking up a utility that you shouldn't be hacking up to ensure a behaviour that can be solved by either using the correct utility instead or by specifying a source/target dependency on the install and not doing the install at all in the case of no change is also orthogonal to the problem at hand. If you are going to go gratuitously hacking install, it might as well be to solve a long standing problem instead of a non-problem. 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?9504042303.AA21054>