Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> I don't think preserving timestamps should be the default behavior, but
> I would support organizing things so that additional options can be
> passed to "install" to make it do whatever the user prefers. But that
> won't work if some installations don't go through install.
Check, but ...
> Btw., a quick test of make -C src/include/ install:
> cp (current code): 0.5 s
> GNU install: 0.6 s
> install-sh: 12.5 s
So this says that there's only a performance issue with install-sh;
but that's used by just a tiny minority of systems anymore. Scraping
the buildfarm's configure results, I find this many animals reporting
each of these choices:
4 /bin/install -c
8 config/install-sh -c
2 /opt/packages/coreutils-8.6/inst/bin/install -c
1 /usr/bin/ginstall -c
100 /usr/bin/install -c
1 /usr/gnu/bin/install -c
The 8 holdouts are
gaur
haddock
hake
hornet
hoverfly
mandrill
sungazer
tern
ie, ancient HPUX, OpenIndiana (Solaris), and AIX, none of which
are likely development platforms anymore --- and if somebody
did care about this, there's nothing stopping them from
installing GNU install on their machine.
So I fear we're optimizing for a case that stopped being mainstream
a decade or more back. I could get behind switching the code back
to using $(INSTALL) for this, and then offering some way to inject
user-selected switches into the $(INSTALL) invocations. That
wouldn't need much more than another gmake macro. (Does there
need to be a way to inject such switches only into header
installations, or is it OK to do it across the board?)
[ wanders away wondering how this'd affect the meson conversion
project ]
regards, tom lane