On Thu, Sep 1, 2022 at 4:12 PM samay sharma wrote:
> Hi,
>
> On Wed, Aug 31, 2022 at 1:42 AM Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
>
>> On 24.08.22 17:30, Andres Freund wrote:
>> >> 0545eec895 meson: Add docs
>> >>
>> >> We should think more about how to arrange the
Andres Freund writes:
> On 2022-09-02 14:17:26 +0700, John Naylor wrote:
>> + # FIXME: -output option is only available in perl 5.9.3 - but that's
>> + # probably a fine minimum requirement?
>>
>> Since we've retired some buildfarm animals recently, it seems the
>> oldest perl there is 5.14?
Hi,
On 2022-09-02 09:35:15 -0700, Andres Freund wrote:
> Part of that is due to some ugly dependencies of src/common on backend headers
> that IMO probably shouldn't exist (e.g. src/common/relpath.c includes
> catalog/pg_tablespace_d.h). Looks like it'd not be hard to get at least the
> _shlib
On Thu, Sep 1, 2022 at 1:12 AM Andres Freund wrote:
> [v12]
+# Build a small utility static lib for the parser. This makes it easier to not
+# depend on gram.h already having been generated for most of the other code
+# (which depends on generated headers having been generated). The generation
Hi,
On Wed, Aug 31, 2022 at 1:42 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 24.08.22 17:30, Andres Freund wrote:
> >> 0545eec895 meson: Add docs
> >>
> >> We should think more about how to arrange the documentation. We
> >> probably don't want to copy-and-paste all the
Hi,
On 2022-08-31 10:28:05 +0200, Peter Eisentraut wrote:
> I found that the perl test modules are not installed. See attached patch to
> correct this.
>
> To the patches:
>
> 4e15ee0e24 Don't hardcode tmp_check/ as test directory for tap tests
> 1a3169bc3f Split TESTDIR into TESTLOGDIR and
On 24.08.22 17:30, Andres Freund wrote:
0545eec895 meson: Add docs
We should think more about how to arrange the documentation. We
probably don't want to copy-and-paste all the introductory and
requirements information. I think we can make this initially much
briefer, like the Windows
I found that the perl test modules are not installed. See attached
patch to correct this.
To the patches:
4e15ee0e24 Don't hardcode tmp_check/ as test directory for tap tests
1a3169bc3f Split TESTDIR into TESTLOGDIR and TESTDATADIR
It's a bit weird that the first patch changes the meaning of
Hi,
On 2022-08-28 12:08:07 -0500, Justin Pryzby wrote:
> with_temp_install is repeated twice in prove_check:
>
> > Subject: [PATCH v12 02/15] Split TESTDIR into TESTLOGDIR and TESTDATADIR
> >
> > - TESTDIR='$(CURDIR)/tmp_check' $(with_temp_install)
> > PGPORT='6$(DEF_PGPORT)' \
> > +
with_temp_install is repeated twice in prove_check:
> Subject: [PATCH v12 02/15] Split TESTDIR into TESTLOGDIR and TESTDATADIR
>
>
> - TESTDIR='$(CURDIR)/tmp_check' $(with_temp_install)
> PGPORT='6$(DEF_PGPORT)' \
> + TESTLOGDIR='$(CURDIR)/tmp_check/log' $(with_temp_install) \
On Sun, Aug 28, 2022 at 1:39 PM Andres Freund wrote:
> On 2022-08-27 18:02:40 -0700, Andres Freund wrote:
> > FWIW, I did notice that netbsd does have working unnamed semaphores. I don't
> > know how long ago they were added, but they apparently didn't work quite
> > right
> > in 2018 [1]. No
Hi,
On 2022-08-27 18:02:40 -0700, Andres Freund wrote:
> FWIW, I did notice that netbsd does have working unnamed semaphores. I don't
> know how long ago they were added, but they apparently didn't work quite right
> in 2018 [1]. No meaningful performance chance in the main regression tests,
>
Hi,
On 2022-08-27 11:04:47 -0700, Andres Freund wrote:
> - choice of semaphore API needs to be cleaned up, that should be easy now, but
> I thought that I needed to get a new version out first
Everytime I look at the existing selection code I get confused, which is part
of why I haven't
On 24.08.22 17:30, Andres Freund wrote:
258f6dc0a7 Don't hardcode tmp_check/ as test directory for tap tests
8ecc33cf04 Split TESTDIR into TESTLOGDIR and TESTDATADIR
I think these patches are split up a bit incorrectly. If you apply
the first patch by itself, then the output appears in
Hi,
On Wed, Aug 24, 2022 at 8:30 AM Andres Freund wrote:
> Hi,
>
> On 2022-08-24 11:39:06 +0200, Peter Eisentraut wrote:
> > I have looked at your branch at 0545eec895:
> >
> > 258f6dc0a7 Don't hardcode tmp_check/ as test directory for tap tests
> > 8ecc33cf04 Split TESTDIR into TESTLOGDIR and
Hi,
On 2022-08-17 14:53:17 -0700, Andres Freund wrote:
> > - In the top-level meson.build, the "renaming" of the Windows system
> > name
> >
> > host_system = host_machine.system() == 'windows' ? 'win32' :
> > host_machine.system()
> > build_system = build_machine.system() ==
Hi,
On 2022-08-24 11:39:06 +0200, Peter Eisentraut wrote:
> I have looked at your branch at 0545eec895:
>
> 258f6dc0a7 Don't hardcode tmp_check/ as test directory for tap tests
> 8ecc33cf04 Split TESTDIR into TESTLOGDIR and TESTDATADIR
>
> I think these patches are split up a bit incorrectly.
I have looked at your branch at 0545eec895:
258f6dc0a7 Don't hardcode tmp_check/ as test directory for tap tests
8ecc33cf04 Split TESTDIR into TESTLOGDIR and TESTDATADIR
I think these patches are split up a bit incorrectly. If you apply
the first patch by itself, then the output appears in
Hi,
On 2022-08-09 08:37:16 -0400, Andrew Dunstan wrote:
> On 2022-08-09 Tu 03:10, Andres Freund wrote:
> > Hi,
> >
> > I was looking at re-unifying gendef2.pl that the meson patchset had
> > introduced
> > for temporary ease during hacking with gendef.pl. Testing that I noticed
> > that
> >
Hi,
On 2022-08-20 09:38:48 +0200, Peter Eisentraut wrote:
> On 17.08.22 23:53, Andres Freund wrote:
> > Any comment on the pg_regress_ecpg commit? I'd like to get that out of the
> > way, and it seems considerably cleaner than the hackery we do right now to
> > make VPATH builds work.
>
> That
On 17.08.22 23:53, Andres Freund wrote:
Any comment on the pg_regress_ecpg commit? I'd like to get that out of the
way, and it seems considerably cleaner than the hackery we do right now to
make VPATH builds work.
That one looks like a very good improvement.
Hi,
On 2022-08-17 15:50:23 +0200, Peter Eisentraut wrote:
> - There are various references to "pch" (pre-compiled headers). Is
> there more discussion anywhere about this? I don't know what this
> would entail or whether there are any drawbacks to be aware of. The
> new *_pch.h files
On 11.08.22 02:20, Andres Freund wrote:
Attached is a new version of the meson patchset. Plenty changes:
I have various bits of comments on this.
- There are various references to "pch" (pre-compiled headers). Is
there more discussion anywhere about this? I don't know what this
would
John Naylor writes:
> I'll volunteer to work on this unless an easier solution happens to
> come along in the next couple days. (aside: guc-file.l doesn't have a
> grammar, so not yet sure if that makes the issue easier or harder...)
That one's probably mostly about the issue mentioned in the
Hi,
On 2022-08-11 10:57:33 +0700, John Naylor wrote:
> I'll volunteer to work on this unless an easier solution happens to
> come along in the next couple days.
Cool!
> (aside: guc-file.l doesn't have a grammar, so not yet sure if that makes the
> issue easier or harder...)
I think we should
On Thu, Aug 11, 2022 at 10:37 AM Tom Lane wrote:
>
> John Naylor writes:
> > With a bit of work, we could probably get rid of those includes. See
> > 27199058d98ef7f for one example.
>
> Yeah --- it would mean creating gram.h files for all the bison grammars
> not just a few of them, but it's
I wrote:
> John Naylor writes:
>> With a bit of work, we could probably get rid of those includes. See
>> 27199058d98ef7f for one example.
> Yeah --- it would mean creating gram.h files for all the bison grammars
> not just a few of them, but it's certainly do-able if there's motivation
> to
John Naylor writes:
> With a bit of work, we could probably get rid of those includes. See
> 27199058d98ef7f for one example.
Yeah --- it would mean creating gram.h files for all the bison grammars
not just a few of them, but it's certainly do-able if there's motivation
to make the changes.
On Thu, Aug 11, 2022 at 12:19 AM Andres Freund wrote:
> I tried to ignore various generated files in the source tree, but I don't
> think it's doable for all of them. Consider
> e.g. src/backend/utils/misc/guc-file.c which is gets built via #include
> "guc-file.c" from gram.c
With a bit of work,
Hi,
On 2022-06-02 10:26:09 -0700, Andres Freund wrote:
> > Could we have the meson build check that, say, if gram.c exists it
> > is newer than gram.y? Or get it to ignore an in-tree gram.c?
>
> I suspect the problem with ignoring is gram.h, that's probably a bit harder to
> ignore.
I tried to
Hi,
On 8/8/22 18:53, Andres Freund wrote:
Bilal's version checked different directories for expected files, but I don't
think that's necessary. Bilal, do you remember why you added that?
This was for not breaking autoconf build. Autoconf wasn't using
expecteddir, so I checked different
On 2022-08-09 Tu 03:10, Andres Freund wrote:
> Hi,
>
> I was looking at re-unifying gendef2.pl that the meson patchset had introduced
> for temporary ease during hacking with gendef.pl. Testing that I noticed that
> either I and my machine is very confused, or gendef.pl's check whether it can
>
Hi,
I was looking at re-unifying gendef2.pl that the meson patchset had introduced
for temporary ease during hacking with gendef.pl. Testing that I noticed that
either I and my machine is very confused, or gendef.pl's check whether it can
skip work is bogus.
I noticed that, despite having code
Hi,
On 2022-07-21 15:26:05 +0300, Bilal Yavuz wrote:
> > On 2022-07-06 11:03:31 +0200, Peter Eisentraut wrote:
> > > dff7b5a960 meson: prereq: regress: allow to specify director containing
> > > expected files.
> > >
> > > This could use a bit more explanation, but it doesn't look
> > >
Hi,
On 2021-10-31 16:24:48 -0700, Andres Freund wrote:
> - support for building docs.
> I couldn't get dbtoepub work in a vpath style build, so I changed that
> to also use pandoc. No idea if anybody uses the epub rules?
combing through various FIXMEs in the meson patch I started to look
Hi,
Sorry for the first email.
On Mon, 18 Jul 2022 at 23:23, Andres Freund wrote:
>
> In
https://postgr.es/m/0e81e45c-c9a5-e95b-2782-ab2dfec8bf57%40enterprisedb.com
> On 2022-07-06 11:03:31 +0200, Peter Eisentraut wrote:
> > dff7b5a960 meson: prereq: regress: allow to specify director
Hi,
On 2022-07-18 23:23:27 +0300, Andres Freund wrote:
> Bilal, Peter previously commented on the pg_regress change for ecpg,
> perhaps
> you can comment on that?
>
> In
> https://postgr.es/m/0e81e45c-c9a5-e95b-2782-ab2dfec8bf57%40enterprisedb.com
> On 2022-07-06 11:03:31 +0200, Peter Eisentraut
Hi,
On 2022-07-18 11:33:09 +0200, Peter Eisentraut wrote:
> The following patches are ok to commit IMO:
>
> a1c5542929 prereq: Deal with paths containing \ and spaces in
> basebackup_to_shell tests
> e37951875d meson: prereq: psql: Output dir and dependency generation for
> sql_help
>
Hi,
On 2022-07-18 11:12:10 +0300, Aleksander Alekseev wrote:
> > Just a quick question - is there a reason for changing the subject of
> > the emails?
> >
> > Not all email clients handle this well, e.g. Google Mail considers
> > this being 10 separate threads. The CF application and/or
> >
On 15.07.22 07:08, Andres Freund wrote:
Attached is v10 of the meson patchset. Lots of small changes, I don't think
anything major. I tried to address most of Peter's feedback for the earlier
patches.
The following patches are ok to commit IMO:
a1c5542929 prereq: Deal with paths containing \
Hi again,
> Just a quick question - is there a reason for changing the subject of
> the emails?
>
> Not all email clients handle this well, e.g. Google Mail considers
> this being 10 separate threads. The CF application and/or
> pgsql-hackers@ archive also don't recognise this as a continuation
Hi Andres,
> Attached is v10 of the meson patchset. Lots of small changes, I don't think
> anything major. I tried to address most of Peter's feedback for the earlier
> patches.
>
> After this I plan to clean up the "export" patch, since that's I think the
> next bigger step, and an improvement
Hi,
On 2022-07-13 08:39:45 +0200, Peter Eisentraut wrote:
> On 06.07.22 15:21, Andres Freund wrote:
> > > - This patch is for unifying the list of languages in NLS, as
> > >previously discussed:https://commitfest.postgresql.org/38/3737/
> > There seems little downside to doing so, so ...
>
>
Hi,
On 2022-07-07 12:09:32 +0200, Peter Eisentraut wrote:
> On 06.07.22 15:21, Andres Freund wrote:
> > > Here is my rough assessment of where we are with this patch set:
> > >
> > > 08b4330ded prereq: deal with \ paths in basebackup_to_shell tests.
> > >
> > > This still needs clarification,
On 06.07.22 15:21, Andres Freund wrote:
bda6a45bae meson: prereq: Refactor PG_TEST_EXTRA logic in autoconf build
I understand the intention behind this, but I think it changes the
behavior in an undesirable way. Before this patch, you can go into
src/test/ssl/ and run make check manually.
On 06.07.22 15:21, Andres Freund wrote:
- This patch is for unifying the list of languages in NLS, as
previously discussed:https://commitfest.postgresql.org/38/3737/
There seems little downside to doing so, so ...
This has been committed, so on the next rebase, the languages arguments
can
On 06.07.22 15:21, Andres Freund wrote:
Here is my rough assessment of where we are with this patch set:
08b4330ded prereq: deal with \ paths in basebackup_to_shell tests.
This still needs clarification, per my previous review.
Hm. I thought I had explained that bit, but apparently not. Well,
Hi
On 2022-07-06 11:03:31 +0200, Peter Eisentraut wrote:
> On 01.07.22 11:33, Andres Freund wrote:
> > Attached is an updated version of the meson patchset. There has been a
> > steady
> > stream of incremental work over the last month, with patches from Peter
> > Eisentraut and Nazir Yavuz.
> >
On 01.07.22 11:33, Andres Freund wrote:
Attached is an updated version of the meson patchset. There has been a steady
stream of incremental work over the last month, with patches from Peter
Eisentraut and Nazir Yavuz.
I tried to address the review comments Peter had downthread about the prep
Hi,
On 2022-07-01 14:01:11 -0500, Justin Pryzby wrote:
> vcvarsall isn't needed in cirrus' "check_world" scripts.
E.g. for the ecpg tests it isn't, except that we don't currently build ecpg on
windows. But I plan to fix that.
> I'm missing any way to re/run cirrus only for msbuild OR ninja OR
vcvarsall isn't needed in cirrus' "check_world" scripts.
I'm missing any way to re/run cirrus only for msbuild OR ninja OR homegrown
with something more granular than "ci-os-only: windows". (The same thing
applies to the mingw patch).
I'll mail shortly about ccache.
--
Justin
On 2022-06-14 20:47:59 +0200, Peter Eisentraut wrote:
> On 14.06.22 20:27, Andres Freund wrote:
> > One thing I'm not quite sure about: Why does the makefile need awareness of
> > the stop files, but Install.pm doesn't? I suspect currently the patch leads
> > to
> > stopwords not being installed
On 14.06.22 20:27, Andres Freund wrote:
One thing I'm not quite sure about: Why does the makefile need awareness of
the stop files, but Install.pm doesn't? I suspect currently the patch leads to
stopwords not being installed on windows anymore?
Install.pm contains this elsewhere:
Hi,
On 2022-06-08 14:33:16 +0200, Peter Eisentraut wrote:
> Attached is a patch the finishes up the work to move the snowball SQL script
> generation into a separate script.
That looks good, merged. I did split the commit, because there's not yet a
meson.build "at the time" of the prereq:
Hi,
On 2022-06-08 08:27:06 +0200, Peter Eisentraut wrote:
> I looked at some of the "prereq" patches again to see what state they are
> in:
>
> commit 351a12f48e395b31cce4aca239b934174b36ea9d
> Author: Andres Freund
> Date: Wed Apr 20 22:46:54 2022
>
> prereq: deal with \ paths in
Attached is a patch the finishes up the work to move the snowball SQL
script generation into a separate script.From 02ca51dfb918666dfde8e48499a4c73afae4e89e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 8 Jun 2022 11:05:31 +0200
Subject: [PATCH] fixup! meson: prereq: move
I looked at some of the "prereq" patches again to see what state they
are in:
commit 351a12f48e395b31cce4aca239b934174b36ea9d
Author: Andres Freund
Date: Wed Apr 20 22:46:54 2022
prereq: deal with \ paths in basebackup_to_shell tests.
This is a new component in PG15, so a fix might be
On Tue, May 24, 2022 at 08:08:26PM +0200, Peter Eisentraut wrote:
> On 18.05.22 21:48, Andres Freund wrote:
>> - GETTIMEOFDAY_1ARG - test doesn't exist - I suspect it might not be
>> necessary
>
> Might be obsolete, consider removing.
I just came across this one independently of what you are
Hi,
On 2022-06-03 12:35:45 +0300, Aleksander Alekseev wrote:
> > Part of the patch series is to use visibility attributes, and your #if
> > TS_EMPTY(PGDLLEXPORT) thing can't handle that.
>
> Out of curiosity, how come a patchset that adds an alternative build system
> changes the visibility
Hi hackers,
> See about line 300 in src/backend/Makefile. In any case, it's
> easy to show by experiment that it does.
`make maintainer-clean` did the trick, thanks. I suggest modifying meson.build
accordingly:
-run make distclean in the source tree.
+run `make maintainer-clean` in the source
Hi,
On 2022-06-02 15:53:50 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Oh. I executed maintainer-clean inside src/backend/parser/, and thus didn't
> > see it getting cleaned up.
>
> > It seems pretty darn grotty that src/backend/parser/Makefile explicitly
> > states
> > that gram.c ...
Andres Freund writes:
> Oh. I executed maintainer-clean inside src/backend/parser/, and thus didn't
> see it getting cleaned up.
> It seems pretty darn grotty that src/backend/parser/Makefile explicitly states
> that gram.c ... aren't cleaned "here", but then src/backend/Makefile does
> clean
Hi,
On 2022-06-02 15:05:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-06-02 13:33:51 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> (*) do we really not have a target that removes bison / flex output?
>
> >> maintainer-clean
>
> > Don't think so:
>
> See about line
Andres Freund writes:
> On 2022-06-02 13:33:51 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> (*) do we really not have a target that removes bison / flex output?
>> maintainer-clean
> Don't think so:
See about line 300 in src/backend/Makefile. In any case, it's
easy to show by
Hi,
On 2022-06-02 13:33:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > (*) do we really not have a target that removes bison / flex output?
>
> maintainer-clean
Don't think so:
# gram.c, gram.h, and scan.c are in the distribution tarball, so they
# are not cleaned here.
clean distclean
Andres Freund writes:
> (*) do we really not have a target that removes bison / flex output?
maintainer-clean
regards, tom lane
Hi,
On 2022-06-02 13:08:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm not quite sure what the proper behaviour is when doing an out-of-tree
> > build with meson (all builds are out-of-tree), with a pre-existing flex /
> > bison output in the source tree that is out of date.
>
>
Andres Freund writes:
> I'm not quite sure what the proper behaviour is when doing an out-of-tree
> build with meson (all builds are out-of-tree), with a pre-existing flex /
> bison output in the source tree that is out of date.
Definitely sounds like a gotcha.
On the one hand, there's been
Hi,
On 2022-06-01 12:39:50 +0300, Aleksander Alekseev wrote:
> > > ```
> > > ../src/include/parser/kwlist.h:332:25: error: ‘PARAMETER’ undeclared here
> > > (not
> > > in a function)
> > > 332 | PG_KEYWORD("parameter", PARAMETER, UNRESERVED_KEYWORD, BARE_LABEL)
> > >
> > >
Hi,
On 2022-06-02 15:34:23 +0300, Aleksander Alekseev wrote:
> Hi Andres,
>
> > Cool. I think I pushed a fix/workaround for the issue now. Still can't
> > decide
> > whether it's apple's or meson's fault.
>
> Many thanks! The fix solved the problem, I can compile with -Dldap=enabled
> now.
>
Hi Andres,
> Cool. I think I pushed a fix/workaround for the issue now. Still can't decide
> whether it's apple's or meson's fault.
Many thanks! The fix solved the problem, I can compile with -Dldap=enabled now.
The code passes the tests too.
> > $ meson configure -Dldap=disabled
> > $ meson
Hi,
On 2022-06-01 12:39:50 +0300, Aleksander Alekseev wrote:
> > > ```
> > > ../src/include/parser/kwlist.h:332:25: error: ‘PARAMETER’ undeclared here
> > > (not
> > > in a function)
> > > 332 | PG_KEYWORD("parameter", PARAMETER, UNRESERVED_KEYWORD, BARE_LABEL)
> > >
> > >
Hi,
On 2022-06-01 06:55:06 +0200, Peter Eisentraut wrote:
>
> On 06.05.22 23:27, Andres Freund wrote:
> > I added pkgconfig since then. They're not exactly the same, but pretty
> > close,
> > except for one thing: Looks like some of the ecpg libraries really should
> > link
> > to some other
Hi Andres,
> What do those extensions use to build? Since the unconference I added some
> rudimentary PGXS compatibility, but it's definitely not complete yet.
We mostly use CMake and Cargo, the Rust package manager. So I don't
anticipate many problems here, just want to make sure it's going to
On 06.05.22 23:27, Andres Freund wrote:
I added pkgconfig since then. They're not exactly the same, but pretty close,
except for one thing: Looks like some of the ecpg libraries really should link
to some other ecpg libs? I think we're missing something there... That then
leads to missing
Hi,
On 2022-05-31 16:49:17 +0300, Aleksander Alekseev wrote:
> I tried the branch on GitHub on MacOS Monterey 12.3.1 and Ubuntu 20.04 LTS.
> I was going to test it against several third party extensions, but it looks
> like
> it is a bit early for this. On Ubuntu I got the following error:
What
Hi Andres,
> Not having a ninja backend etc didn't strike me as great either - the builds
> with scons I've done weren't fast at all.
I must admit, personally I never used Scons, I just know that it was considered
(an / the only?) alternative to CMake for many years. The Scons 4.3.0 release
Hi,
On 2022-05-26 11:47:13 +0300, Aleksander Alekseev wrote:
> Thanks for working on this! I'm very enthusiastic about this effort and I was
> glad to see on PGCon Unconference that the majority of the community seems
> to be as well.
>
> > The halfway decent list includes, I think:
> > 1) cmake
Hi Andres,
Thanks for working on this! I'm very enthusiastic about this effort and I was
glad to see on PGCon Unconference that the majority of the community seems
to be as well.
> The halfway decent list includes, I think:
> 1) cmake
> 2) bazel
> 3) meson
Was SCons considered as an option? It
Andres Freund writes:
> On 2022-05-25 21:38:33 -0400, Tom Lane wrote:
>> I think the main thing I didn't like about the way you have it in the
>> meson file is the loss of greppability.
> What would you want to grep for? Places that specify additional flags? Or just
> places using flex?
Well,
Hi,
On 2022-05-25 21:38:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > in the meson unconference session you'd spotted flex flags for
> > psqlscanslash.l
> > (I think) being "hardcoded". As far as I can tell that's largely just copied
> > from the Makefile):
>
> >
Andres Freund writes:
> in the meson unconference session you'd spotted flex flags for psqlscanslash.l
> (I think) being "hardcoded". As far as I can tell that's largely just copied
> from the Makefile):
> src/backend/parser/Makefile:scan.c: FLEXFLAGS = -CF -p -p
>
Hi Tom,
in the meson unconference session you'd spotted flex flags for psqlscanslash.l
(I think) being "hardcoded". As far as I can tell that's largely just copied
from the Makefile):
src/backend/parser/Makefile:scan.c: FLEXFLAGS = -CF -p -p
src/backend/utils/adt/Makefile:jsonpath_scan.c:
On 18.05.22 21:48, Andres Freund wrote:
- CONFIGURE_ARGS - empty in meson, not clear what to fill it with
Ok to leave empty for now.
- GETTIMEOFDAY_1ARG - test doesn't exist - I suspect it might not be necessary
Might be obsolete, consider removing.
- PACKAGE_STRING, PACKAGE_TARNAME -
Hi,
On 2022-05-18 10:30:12 +0200, Peter Eisentraut wrote:
> Here are some more patches that clean up various minor issues.
I rebased the meson tree, squashed a lot of the existing commits, merged your
changes, and fixed a few more differences between autoconf and meson.
For me the difference
Here are some more patches that clean up various minor issues.From bc06fda7198d182dce73f39cfff8e4724e00b12d Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 4 May 2022 14:38:02 +0200
Subject: [PATCH 1/7] meson: Put genbki header files back into original order
The order affects the
Hi,
On 2022-05-16 17:47:24 +0200, Peter Eisentraut wrote:
> On 12.05.22 21:30, Andres Freund wrote:
> > On 2022-05-11 12:18:58 +0200, Peter Eisentraut wrote:
> > > I fixed the Perl detection issue in my macOS environment that I had
> > > reported
> > > a while ago.
> >
> > Hm. I wonder if it's
On 2022-05-16 17:48:08 +0200, Peter Eisentraut wrote:
> On 14.05.22 01:17, Andres Freund wrote:
> > On 2022-05-11 12:18:58 +0200, Peter Eisentraut wrote:
> > > This currently only works on macOS. The dtrace -G calls needed on
> > > other platforms are not implemented yet.
> >
> > I looked into
On 14.05.22 01:17, Andres Freund wrote:
On 2022-05-11 12:18:58 +0200, Peter Eisentraut wrote:
This currently only works on macOS. The dtrace -G calls needed on
other platforms are not implemented yet.
I looked into that part. The make rule passes all the backend object files as
an option,
On 12.05.22 21:30, Andres Freund wrote:
On 2022-05-11 12:18:58 +0200, Peter Eisentraut wrote:
I fixed the Perl detection issue in my macOS environment that I had reported
a while ago.
Hm. I wonder if it's right to check with is_file() - perhaps there are
platforms that have split off the
Hi,
On 2022-05-11 12:18:58 +0200, Peter Eisentraut wrote:
> This currently only works on macOS. The dtrace -G calls needed on
> other platforms are not implemented yet.
I looked into that part. The make rule passes all the backend object files as
an option, but it's not clear to me where / why
Hi,
On 2022-05-11 12:18:58 +0200, Peter Eisentraut wrote:
> I fixed the Perl detection issue in my macOS environment that I had reported
> a while ago.
Hm. I wonder if it's right to check with is_file() - perhaps there are
platforms that have split off the include directory?
> Then I added in
More patches:
I fixed the Perl detection issue in my macOS environment that I had
reported a while ago.
Then I added in support for all configure options that had not been
ported over yet. Some of these are rather trivial.
After that, these configure options don't have an equivalent yet:
On 06.05.22 23:27, Andres Freund wrote:
Re symlink: Do you have an opion about dropping the symlink vs implementing it
(likely via a small helper script?)?
I think the postmaster symlink could be dropped. The postmaster man
page has been saying that it's deprecated since 2006.
Hi,
On 2022-05-06 14:27:24 -0700, Andres Freund wrote:
> > 0003-meson-Install-all-server-headers.patch
> >
> > With this, all the server headers installed by a makefile-based build are
> > installed. I tried to strike a balance between using install_subdir() with
> > exclude list versus listing
Hi,
On 2022-04-21 17:34:47 -0400, Tom Lane wrote:
> FWIW, I don't think that either gaur or prairiedog need be factored into
> this conversation. They cannot build ninja at all for lack of ,
> so whether they could run meson is pretty much beside the point.
Yea.
> (I wonder if we should stick
Hi,
On 2022-05-04 13:53:54 +0200, Peter Eisentraut wrote:
> 0001-meson-Assorted-compiler-test-tweaks.patch
>
> I was going through a diff of pg_config.h between old and new build and
> found a few omissions and small differences.
Thanks, merged that.
> is of course annoying and can be removed
More patches:
0001-meson-Assorted-compiler-test-tweaks.patch
I was going through a diff of pg_config.h between old and new build and
found a few omissions and small differences.
Some of the
blah ? 1 : false
is of course annoying and can be removed eventually, but it's useful
when
Hi,
On 2022-05-02 16:47:43 +0200, Peter Eisentraut wrote:
> On 29.04.22 19:46, Andres Freund wrote:
> > explicitly using shared_library() rather than library()
>
> Why is that? We do build static libraries right now, so using library()
> would seem more suitable for that.
When I wrote this I
On 29.04.22 19:46, Andres Freund wrote:
explicitly using shared_library() rather than library()
Why is that? We do build static libraries right now, so using library()
would seem more suitable for that.
101 - 200 of 348 matches
Mail list logo
