On 26.01.23 19:05, Andres Freund wrote:
Oh, that is interesting. In that case, this is not the right patch. We
should proceed with my previous patch in [0] then.
WFM.
I still think it'd be slightly more legible if we tested the prefix for
postgres|pgsql once, rather than do the per-variable
On 2023-01-26 10:20:58 +0100, Peter Eisentraut wrote:
> On 19.01.23 21:45, Andres Freund wrote:
> > Hi,
> >
> > On 2023-01-19 21:37:15 +0100, Peter Eisentraut wrote:
> > > On 11.01.23 12:05, Peter Eisentraut wrote:
> > > > I think there is also an adjacent issue: The subdir options may be
> > >
On 19.01.23 21:45, Andres Freund wrote:
Hi,
On 2023-01-19 21:37:15 +0100, Peter Eisentraut wrote:
On 11.01.23 12:05, Peter Eisentraut wrote:
I think there is also an adjacent issue: The subdir options may be
absolute or relative. So if you specify --prefix=/usr/local and
Hi,
On 2023-01-19 21:37:15 +0100, Peter Eisentraut wrote:
> On 11.01.23 12:05, Peter Eisentraut wrote:
> > I think there is also an adjacent issue: The subdir options may be
> > absolute or relative. So if you specify --prefix=/usr/local and
> > --sysconfdir=/etc/postgresql, then
> >
> >
On 11.01.23 12:05, Peter Eisentraut wrote:
I think there is also an adjacent issue: The subdir options may be
absolute or relative. So if you specify --prefix=/usr/local and
--sysconfdir=/etc/postgresql, then
config_paths_data.set_quoted('SYSCONFDIR', dir_prefix / dir_sysconf)
would
On 04.01.23 23:53, Andres Freund wrote:
dir_data = get_option('datadir')
-if not (dir_data.contains('pgsql') or dir_data.contains('postgres'))
+if not ((dir_prefix/dir_data).contains('pgsql') or
(dir_prefix/dir_data).contains('postgres'))
dir_data = dir_data / pkg
endif
Hm. Perhaps we
Hi,
On 2023-01-04 23:17:30 +0100, Peter Eisentraut wrote:
> I meant the latter, which I see is already in there, but it doesn't actually
> fully work. It only looks at the subdirectory (like "lib"), not the whole
> path (like "/usr/local/pgsql/lib"). With the attached patch I have it
> working
On 04.01.23 20:35, Andres Freund wrote:
Unless someone comes up with a proposal to address the above broader issues,
also taking into account current packaging practices etc., then I think we
should do a short-term solution to either port the subdir-appending to the
meson scripts or remove it
Hi,
On 2023-01-04 16:18:38 -0500, Tom Lane wrote:
> Robert Haas writes:
> > If we don't do as Peter suggests, then any difference between the
> > results of one build system and the other could either be a bug or an
> > intentional deviation. There will be no easy way to know which it is.
> >
Robert Haas writes:
> If we don't do as Peter suggests, then any difference between the
> results of one build system and the other could either be a bug or an
> intentional deviation. There will be no easy way to know which it is.
> And if or when people switch build systems, stuff will be
On Wed, Jan 4, 2023 at 2:35 PM Andres Freund wrote:
> > I think we should get the two build systems to produce the same installation
> > layout when given equivalent options.
>
> I'm not convinced that that's the right thing to do. Distributions have
> helper infrastructure for buildsystems - why
Hi,
On 2023-01-04 12:35:35 +0100, Peter Eisentraut wrote:
> On 16.11.22 18:07, Andres Freund wrote:
> > > > If I just want to install postgres into a prefix without 'postgresql'
> > > > added in
> > > > a bunch of directories, e.g. because I already have pg-$version to be
> > > > in the
> > > >
On 16.11.22 18:07, Andres Freund wrote:
If I just want to install postgres into a prefix without 'postgresql' added in
a bunch of directories, e.g. because I already have pg-$version to be in the
prefix, there's really no good way to do so - you can't even specify
--sysconfdir or such, because
Hi,
On 2022-11-16 11:54:10 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-11-16 10:53:59 +0100, Peter Eisentraut wrote:
> >> Could you explain this in more detail?
>
> > If I just want to install postgres into a prefix without 'postgresql' added
> > in
> > a bunch of directories,
Andres Freund writes:
> On 2022-11-16 10:53:59 +0100, Peter Eisentraut wrote:
>> Could you explain this in more detail?
> If I just want to install postgres into a prefix without 'postgresql' added in
> a bunch of directories, e.g. because I already have pg-$version to be in the
> prefix,
Hi,
On 2022-11-16 10:53:59 +0100, Peter Eisentraut wrote:
> On 16.11.22 00:40, Andres Freund wrote:
> > Somewhat relatedly, I wonder if we should have a better way to
> > enable/disable
> > the 'pgsql' path logic. It's pretty annoying that prefix basically doesn't
> > work if it doesn't contain
On 16.11.22 00:40, Andres Freund wrote:
Somewhat relatedly, I wonder if we should have a better way to enable/disable
the 'pgsql' path logic. It's pretty annoying that prefix basically doesn't
work if it doesn't contain 'pgsql' or 'postgres'.
Could you explain this in more detail?
Hi,
On 2022-11-15 16:08:35 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2022-11-15 Tu 14:04, Andres Freund wrote:
> >> I don't think it's a virtue to break the layout of the platform by
> >> e.g. installing 64bit libs into the directory containing 32bit libs.
>
> > You might end up
Andrew Dunstan writes:
> On 2022-11-15 Tu 14:04, Andres Freund wrote:
>> I don't think it's a virtue to break the layout of the platform by
>> e.g. installing 64bit libs into the directory containing 32bit libs.
> You might end up surprising people who have installed from source for
> years and
On 2022-11-15 Tu 14:04, Andres Freund wrote:
>> But ISTM we shouldn't be presuming what packagers will do, and that
>> there is some virtue in having a default layout under ${prefix} that is
>> consistent across platforms, as is now the case with autoconf/configure.
> I don't think it's a virtue
Hi,
On 2022-11-15 08:04:29 -0500, Andrew Dunstan wrote:
> On 2022-11-14 Mo 18:24, Andres Freund wrote:
> > Hi,
> >
> > On 2022-11-14 17:41:54 -0500, Andrew Dunstan wrote:
> >> Here's a couple of things I've noticed.
> >>
> >>
> >> andrew@ub22:HEAD $ inst.meson/bin/pg_config --libdir --ldflags
>
On 15.11.22 00:48, Andres Freund wrote:
We effectively do that with autoconf as well, except that we don't mention
that in pg_config --ldflags. Our linking rules include CFLAGS, see e.g.:
%: %.o
$(CC) $(CFLAGS) $^ $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)
postgres: $(OBJS)
On 2022-11-14 Mo 18:24, Andres Freund wrote:
> Hi,
>
> On 2022-11-14 17:41:54 -0500, Andrew Dunstan wrote:
>> Here's a couple of things I've noticed.
>>
>>
>> andrew@ub22:HEAD $ inst.meson/bin/pg_config --libdir --ldflags
>> /home/andrew/pgl/pg_head/root/HEAD/inst.meson/lib/x86_64-linux-gnu
>>
Hi,
On 2022-11-15 08:22:59 +0900, Michael Paquier wrote:
> I pass down some custom CFLAGS to the meson command as well, and these find
> their way to LDFLAGS on top of CFLAGS for the user-defined entries. I would
> not have expected that, either.
We effectively do that with autoconf as well,
Hi,
On 2022-11-14 17:41:54 -0500, Andrew Dunstan wrote:
> Here's a couple of things I've noticed.
>
>
> andrew@ub22:HEAD $ inst.meson/bin/pg_config --libdir --ldflags
> /home/andrew/pgl/pg_head/root/HEAD/inst.meson/lib/x86_64-linux-gnu
> -fuse-ld=lld -DCOPY_PARSE_PLAN_TREES
On Mon, Nov 14, 2022 at 05:41:54PM -0500, Andrew Dunstan wrote:
> Also, why have the CPPFLAGS made their way into the LDFLAGS? That seems
> wrong.
Not only CPPFLAGS. I pass down some custom CFLAGS to the meson
command as well, and these find their way to LDFLAGS on top of
CFLAGS for the
Here's a couple of things I've noticed.
andrew@ub22:HEAD $ inst.meson/bin/pg_config --libdir --ldflags
/home/andrew/pgl/pg_head/root/HEAD/inst.meson/lib/x86_64-linux-gnu
-fuse-ld=lld -DCOPY_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST
-DWRITE_READ_PARSE_PLAN_TREES
Are we really intending
27 matches
Mail list logo
