On 12/09/2022 18:49, Peter Eisentraut wrote:
On 09.09.22 21:23, Heikki Linnakangas wrote:
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
On 09.09.22 21:23, Heikki Linnakangas wrote:
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) invocat
On Fri, Sep 09, 2022 at 10:23:57PM +0300, Heikki Linnakangas wrote:
> On 11/01/2022 00:03, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > I don't think preserving timestamps should be the default behavior, but
> > > I would support organizing things so that additional options can be
> > > pass
On 11/01/2022 00:03, Tom Lane wrote:
Peter Eisentraut 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 ins
Peter Eisentraut 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 i
On 04.01.22 22:21, Tom Lane wrote:
However, there's another problem with using INSTALL_DATA as a solution
to this issue: why would you expect that to preserve timestamps?
install-sh won't. I see that /usr/bin/install (which configure picks
on my RHEL box) won't preserve them by default, but it h
Peter Eisentraut writes:
> On 06.12.21 12:15, Michael Paquier wrote:
>> FWIW, I am not on board with changing build semantics or any
>> assumptions the header installation relies on either, but I could see
>> a point in switching back to INSTALL_DATA instead of cp to be
>> consistent with the rest
On 06.12.21 12:15, Michael Paquier wrote:
FWIW, I am not on board with changing build semantics or any
assumptions the header installation relies on either, but I could see
a point in switching back to INSTALL_DATA instead of cp to be
consistent with the rest of the build, iff the argument made b
On 06.12.21 07:51, Tom Lane wrote:
TBH, I am not convinced that the complained-of case is enough of a
problem to justify any change in our build rules, even if there
weren't any semantic issues. If you are worried about build times,
you should be using ccache, and IME builds using ccache are n
On Mon, Dec 06, 2021 at 01:51:39AM -0500, Tom Lane wrote:
> TBH, I am not convinced that the complained-of case is enough of a
> problem to justify any change in our build rules, even if there
> weren't any semantic issues. If you are worried about build times,
> you should be using ccache, and IM
Michael Paquier writes:
> On Tue, Oct 12, 2021 at 01:22:50PM +0300, Alexander Kuzmenkov wrote:
>> This patch adds `-p` switch to `cp` invocation in
>> these files, to make it preserve timestamps.
> The use of cp instead of $(INSTALL_DATA) for the installation of the
> headers comes from a703269,
On Tue, Oct 12, 2021 at 01:22:50PM +0300, Alexander Kuzmenkov wrote:
> I noticed that `make install` updates modification time for all
> installed headers. This leads to recompilation of all dependent
> objects, which is inconvenient for example when working on a
> third-party extension. A way to s
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Personally, I don't often encounter the problem that Alexande
13 matches
Mail list logo
