Re: hardcoded -C argument to ${INSTALL}

At 8:50 AM +1000 5/7/03, Bruce Evans wrote:
>On Tue, 6 May 2003, Lars Eggert wrote:
>
>  > I'm putting a script together that will remove stale pieces
>  > after an installworld, and my find+mtime approach chokes,
>  > because some uses of ${INSTALL} in the Makefiles hardcode
>  > the -C argument,  [...etc...]
>  >
>  > Can the -C be removed without ill effects?
>
>-C is important for includes because it prevents most executables
>(including freshly built ones) becoming out of date every time
>you install includes.
>
>-C is used for very important executables like ld-elf.so.1
>for its side effect of giving an atomic-as-possible install.
>Atomic-as-possible installs should be the default, and
>install(1) has made some progress towards this, but it is not
>there yet -- by default, it still begins with unlinking the
>target.

I think this "remove stale pieces" issue is one that we have
to find a decent solution to, because it keeps popping up
every few months (in slightly different contexts), and it's
going to drive us all nuts.  I made a few stabs at trying to
implement a solution, and but I never trotted those out
because the results were not particularly appealing.

Here is my current idea, but I have not had time to try and
implement it.  Modify 'install' to have some kind of log-file
capability.  Whether or not 'install' changes the destination,
it *does* know that it was asked to change that destination,
and could write a line out to a log file for that.

My next thought is that install-log file could get pretty large
and unwieldy.  In order to keep that a reasonable size, it might
make sense to have 'install' only write a line to that log file
if it was asked to install the file, but if after the install
process the last-mod-time on the file is not "recent enough"
(for whatever reasons, such as -C or -p).

We could then write a process that goes thru all of whatever-
directories-we-care-about, have it ignore all files with a
"recent" last-change-time, and then look into this log file
for any of the remaining filenames.

At the moment, I think this is the most promising and least-
disruptive solution to the stale-files problem.  Everything in
the buildworld/installworld process should (I hope) be exactly
the same as it is now, with all the same options that are
available now, except you would have the option of generating
this one additional file.  Then, with the combination of a new
program and this one additional file, the end user could track
down what files are stale.

I think it's important that we come up with a solution that can
be used by anyone, and not a solution that forces a restriction
on what options can be given to the 'install' commands.

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu