Обсуждение: Why does pg_bsd_indent need to be installed?
Why does pgindent require that pg_bsd_indent be installed in the path? Couldn't pgindent call the pg_bsd_indent built inside the tree? That would make the whole process much smoother.
Peter Eisentraut <peter@eisentraut.org> writes:
> Why does pgindent require that pg_bsd_indent be installed in the path?
> Couldn't pgindent call the pg_bsd_indent built inside the tree? That
> would make the whole process much smoother.
Well, the current expectation is that you run it in a distclean'd
tree, in which case it won't be there. VPATH builds would have
a problem finding it as well.
I'm not sure if there's any problem in applying it in a built-out
tree, but the VPATH scenario seems like a problem in any case,
especially since (IIUC) meson builds have to be done that way.
I wouldn't object to adding more logic to the calling script
to support multiple usage scenarios, of course.
regards, tom lane
Hi, On 2023-05-25 09:09:45 -0400, Tom Lane wrote: > Peter Eisentraut <peter@eisentraut.org> writes: > > Why does pgindent require that pg_bsd_indent be installed in the path? > > Couldn't pgindent call the pg_bsd_indent built inside the tree? That > > would make the whole process much smoother. > > Well, the current expectation is that you run it in a distclean'd > tree, in which case it won't be there. VPATH builds would have > a problem finding it as well. > > I'm not sure if there's any problem in applying it in a built-out > tree, but the VPATH scenario seems like a problem in any case, > especially since (IIUC) meson builds have to be done that way. Isn't the situation actually *easier* in VPATH builds? There's no build artifacts in the source tree, so you can just invoke the pg_bsd_indent built in the build directory against the source tree, without any problems? I'd like to add a build system target for reindenting with the in-tree pg_bsd_indent, obviously with the right dependencies to build pg_bsd_indent first. And yes, meson only supports building in a separate directory (which obviously can be inside the source directory, although I don't do that, because the autoconf vpath build copies such directories, which isn't fun). Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2023-05-25 09:09:45 -0400, Tom Lane wrote:
>> Peter Eisentraut <peter@eisentraut.org> writes:
>>> Why does pgindent require that pg_bsd_indent be installed in the path?
> Isn't the situation actually *easier* in VPATH builds? There's no build
> artifacts in the source tree, so you can just invoke the pg_bsd_indent built
> in the build directory against the source tree, without any problems?
Well, if you know where the build directory is, sure. But any way you
slice it there is an extra bit of knowledge required. Since pg_bsd_indent
changes so seldom, keeping it in your PATH is at least as easy as any
other solution, IMO.
Another reason why I like to do it that way is that it supports running
pgindent on files that aren't in the source tree at all, which suits
some old habits of mine.
But, as I said before, I'm open to adding support for other scenarios
as long as we don't remove that one.
regards, tom lane
Hi, On 2023-05-25 13:05:57 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2023-05-25 09:09:45 -0400, Tom Lane wrote: > >> Peter Eisentraut <peter@eisentraut.org> writes: > >>> Why does pgindent require that pg_bsd_indent be installed in the path? > > > Isn't the situation actually *easier* in VPATH builds? There's no build > > artifacts in the source tree, so you can just invoke the pg_bsd_indent built > > in the build directory against the source tree, without any problems? > > Well, if you know where the build directory is, sure. I'm imaginging adding make / meson targets 'indent-tree' and 'indent-head' or such. Obviously the buildsystem knows where the source dir is, and you'd invoke it in the build dir, so it'd know all that'd need to be known. Attached is a prototype adding such meson targets. It's easier with a parameter telling pgindent where the source tree is, so I addeded that too (likely would need to be cleaned up some). > Since pg_bsd_indent > changes so seldom, keeping it in your PATH is at least as easy as any > other solution, IMO. > > Another reason why I like to do it that way is that it supports running > pgindent on files that aren't in the source tree at all, which suits > some old habits of mine. > But, as I said before, I'm open to adding support for other scenarios > as long as we don't remove that one. I can't imagine that we'd remove support for doing so... Greetings, Andres Freund
Вложения
On 25.05.23 13:05, Tom Lane wrote: > Well, if you know where the build directory is, sure. But any way you > slice it there is an extra bit of knowledge required. Since pg_bsd_indent > changes so seldom, keeping it in your PATH is at least as easy as any > other solution, IMO. The reason I bumped into this is that 15 and 16 use different versions of pg_bsd_indent, so you can't just keep one copy in, like, ~/bin/.
Peter Eisentraut <peter@eisentraut.org> writes:
> On 25.05.23 13:05, Tom Lane wrote:
>> Well, if you know where the build directory is, sure. But any way you
>> slice it there is an extra bit of knowledge required. Since pg_bsd_indent
>> changes so seldom, keeping it in your PATH is at least as easy as any
>> other solution, IMO.
> The reason I bumped into this is that 15 and 16 use different versions
> of pg_bsd_indent, so you can't just keep one copy in, like, ~/bin/.
Well, personally, I never bother to adjust patches to the indentation
rules of old versions, so using the latest pg_bsd_indent suffices.
regards, tom lane
On Wed, May 31, 2023 at 01:21:05PM -0400, Tom Lane wrote: > Peter Eisentraut <peter@eisentraut.org> writes: > > On 25.05.23 13:05, Tom Lane wrote: > >> Well, if you know where the build directory is, sure. But any way you > >> slice it there is an extra bit of knowledge required. Since pg_bsd_indent > >> changes so seldom, keeping it in your PATH is at least as easy as any > >> other solution, IMO. > > > The reason I bumped into this is that 15 and 16 use different versions > > of pg_bsd_indent, so you can't just keep one copy in, like, ~/bin/. > > Well, personally, I never bother to adjust patches to the indentation > rules of old versions, so using the latest pg_bsd_indent suffices. I guess we could try looking for pg_bsd_indent-$MAJOR_VERSION first, then pg_bsd_indent. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
On 2023-May-31, Bruce Momjian wrote: > I guess we could try looking for pg_bsd_indent-$MAJOR_VERSION first, > then pg_bsd_indent. Do you mean with $MAJOR_VERSION being Postgres' version? That means we need to install a new symlink every year, even when pg_bsd_indent doesn't change. I'd rather have it call pg_bsd_indent-$INDENT_VERSION first, and pg_bsd_indent if that doesn't exist. I already have it that way. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Do you mean with $MAJOR_VERSION being Postgres' version? That means we
> need to install a new symlink every year, even when pg_bsd_indent
> doesn't change. I'd rather have it call pg_bsd_indent-$INDENT_VERSION
> first, and pg_bsd_indent if that doesn't exist. I already have it that
> way.
Sounds reasonable.
regards, tom lane
On Tue, Jun 20, 2023 at 06:54:56PM +0200, Álvaro Herrera wrote: > On 2023-May-31, Bruce Momjian wrote: > > > I guess we could try looking for pg_bsd_indent-$MAJOR_VERSION first, > > then pg_bsd_indent. > > Do you mean with $MAJOR_VERSION being Postgres' version? That means we > need to install a new symlink every year, even when pg_bsd_indent > doesn't change. I'd rather have it call pg_bsd_indent-$INDENT_VERSION > first, and pg_bsd_indent if that doesn't exist. I already have it that > way. Yes, your idea makes more sense. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.