convert libpq uri-regress tests to tap test
Hi,
When verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
another way, it seems better to convert it to a tap test.
I hope others agree?
Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.
For now I've left it in src/interfaces/libpq/test, with the test in
t/001_uri.pl. But we should at least get rid of the test/...
Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as well?
The tap test needs a bit more polish, mostly posted this to get some feedback
before wasting more time :)
Greetings,
Andres Freund
Attachments:
On 2/23/22 15:30, Andres Freund wrote:
Hi,
When verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
another way, it seems better to convert it to a tap test.I hope others agree?
yes
Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.For now I've left it in src/interfaces/libpq/test, with the test in
t/001_uri.pl. But we should at least get rid of the test/...Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as well?
WFM
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 23 Feb 2022, at 21:30, Andres Freund <andres@anarazel.de> wrote:
When verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
another way, it seems better to convert it to a tap test.I hope others agree?
Many +1's on that.
The tap test needs a bit more polish, mostly posted this to get some feedback
before wasting more time :)
Skimming the new test it seems structurally fine to me.
--
Daniel Gustafsson https://vmware.com/
Andrew Dunstan <andrew@dunslane.net> writes:
On 2/23/22 15:30, Andres Freund wrote:
Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as well?
WFM
+1
regards, tom lane
Hi,
On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 2/23/22 15:30, Andres Freund wrote:
Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as well?WFM
+1
Cool.
One question on making that happen: Right now the makefiles building C stuff
in src/test/modules all have the contrib-style stanza to build via pgxs. But
afaics pgxs doesn't support building multiple programs. Which
src/test/modules/libpq would need to.
Aaics there's currently no way to have Mkvcbuild.pm build multiple programs in
one dir via its makefile parsing stuff? Andrew, any suggestions for not
needing to spell this out in both the makefile and Mkvcbuild.pm?
Separately: I don't really understand why we do the whole if USE_PGXS dance in
src/test/modules?
- Andres
On 2022-Feb-23, Andres Freund wrote:
When verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
another way, it seems better to convert it to a tap test.I hope others agree?
WFM.
Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as well?
Well, building multiple binaries would require some trickery that might
be excessive for this little tool. But +1 to that on principle.
--
Ãlvaro Herrera Valdivia, Chile â https://www.EnterpriseDB.com/
"La virtud es el justo medio entre dos defectos" (Aristóteles)
On 2022-Feb-23, Andres Freund wrote:
Separately: I don't really understand why we do the whole if USE_PGXS dance in
src/test/modules?
Yeah, it seems a bit silly. I'm not opposed to making these makefiles
unconditionally do the PGXS thing -- or the non-PGXS thing, if that
makes it easier to build multiple binaries.
--
Ãlvaro Herrera Valdivia, Chile â https://www.EnterpriseDB.com/
"La grandeza es una experiencia transitoria. Nunca es consistente.
Depende en gran parte de la imaginación humana creadora de mitos"
(Irulan)
On 2/23/22 16:16, Andres Freund wrote:
Hi,
On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 2/23/22 15:30, Andres Freund wrote:
Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as well?WFM
+1
Cool.
One question on making that happen: Right now the makefiles building C stuff
in src/test/modules all have the contrib-style stanza to build via pgxs. But
afaics pgxs doesn't support building multiple programs. Which
src/test/modules/libpq would need to.
That's my understanding also.
Aaics there's currently no way to have Mkvcbuild.pm build multiple programs in
one dir via its makefile parsing stuff? Andrew, any suggestions for not
needing to spell this out in both the makefile and Mkvcbuild.pm?
Well, it should be a SMOC. If you can solve the first problem I'm sure I
can come up with a solution for Mkvcbuild.pm. But until we see the shape
of the pgxs changes, planning for Mkcvbuild.pm changes seems remature.
Separately: I don't really understand why we do the whole if USE_PGXS dance in
src/test/modules?
ENOCLUE
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
On 2022-Feb-23, Andres Freund wrote:
Separately: I don't really understand why we do the whole if USE_PGXS dance in
src/test/modules?
Yeah, it seems a bit silly. I'm not opposed to making these makefiles
unconditionally do the PGXS thing -- or the non-PGXS thing, if that
makes it easier to build multiple binaries.
Agreed, we could easily lose that. I think we only do it in contrib
to serve as an example of how to use PGXS ... although considering
we're not *testing* that build mode, one wonders how much that proves.
In any case, src/test/modules doesn't have to do it.
regards, tom lane
On 23.02.22 21:30, Andres Freund wrote:
hen verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
another way, it seems better to convert it to a tap test.I hope others agree?
Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.
libpq TAP tests should be in src/interfaces/libpq/t/.
I think there were issues that the build farm wouldn't pick up a test
located there, but that should be fixed rather than worked around.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 23.02.22 21:30, Andres Freund wrote:
Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.
libpq TAP tests should be in src/interfaces/libpq/t/.
I think there were issues that the build farm wouldn't pick up a test
located there, but that should be fixed rather than worked around.
That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library. I don't agree with intermixing such code with libpq
itself, independently of any buildsystem issues (which there
might well be). So I think the design of putting such tests under
src/modules is fine.
regards, tom lane
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 23.02.22 21:30, Andres Freund wrote:
Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.libpq TAP tests should be in src/interfaces/libpq/t/.
I think there were issues that the build farm wouldn't pick up a test
located there, but that should be fixed rather than worked around.That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library. I don't agree with intermixing such code with libpq
itself, independently of any buildsystem issues (which there
might well be).
Such things could be put under src/interfaces/libpq/test, or some other
subdirectory. We already have src/interfaces/ecpg/test.
So I think the design of putting such tests under
src/modules is fine.
I don't get what the rationale for that would be. libpq tests are not
"modules" of any kind.
If I'm working on libpq, I want to do make && make check inside the
libpq source directory.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
libpq TAP tests should be in src/interfaces/libpq/t/.
That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.
Such things could be put under src/interfaces/libpq/test, or some other
subdirectory. We already have src/interfaces/ecpg/test.
OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said. I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.
regards, tom lane
On 2/23/22 20:52, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
libpq TAP tests should be in src/interfaces/libpq/t/.
That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.Such things could be put under src/interfaces/libpq/test, or some other
subdirectory. We already have src/interfaces/ecpg/test.OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said. I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.
It won't without some adjustment.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 24.02.22 02:52, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
libpq TAP tests should be in src/interfaces/libpq/t/.
That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.Such things could be put under src/interfaces/libpq/test, or some other
subdirectory. We already have src/interfaces/ecpg/test.OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said. I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.
I think the TAP scripts should be in src/interfaces/libpq/t/, as usual.
The supporting code snippets could live in some other directory under
src/interfaces/libpq/, which might be called "test" or something else,
not that important.
I think we should pick a layout that is proper and future-proof and then
adjust the buildfarm client as necessary. The issue of writing
libpq-specific tests has come up a few times recently; I think it would
be worth finding a proper solution to this that would facilitate that
work in the future.
Hi,
On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
supporting code snippets could live in some other directory under
src/interfaces/libpq/, which might be called "test" or something else, not
that important.
Why not in t/? We can't easily build the test programs in libpq/ itself, but
libpq/t should be fairly doable.
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
supporting code snippets could live in some other directory under
src/interfaces/libpq/, which might be called "test" or something else, not
that important.
Why not in t/? We can't easily build the test programs in libpq/ itself, but
libpq/t should be fairly doable.
I think that having t/ directories contain only Perl test scripts
is a good convention that we should stick to. Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.
regards, tom lane
Hi,
On 2022-02-24 10:17:28 -0500, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
supporting code snippets could live in some other directory under
src/interfaces/libpq/, which might be called "test" or something else, not
that important.Why not in t/? We can't easily build the test programs in libpq/ itself, but
libpq/t should be fairly doable.I think that having t/ directories contain only Perl test scripts
is a good convention that we should stick to. Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.
That exists today and continues to exist in the patch upthread, so it's easy
;). I just need to move the libpq/test/t to libpq/t and adjust the binary
path.
One annoying bit is that our current tap invocation infrastructure for msvc
won't know how to deal with that. We put the build directory containing t/
onto PATH, but that won't work for test/. But we also don't want to install
test binaries. Not sure what the solution for that is.
Even on !windows, we only know how to find "test executables" in tap tests via
PATH. We're in the source dir, so we can't just do test/executable.
I probably just need another coffee, but right now I don't even see how to add
anything to PATH given $(prove_check)'s definition - it ends up with multiple
shells. We can fix that by using && in the definition, which might be a good
thing anyway?
Attached three patches:
0001: Convert src/interfaces/libpq/test to a tap test
0002: Add tap test infrastructure to src/interfaces/libpq
0003: Move libpq_pipeline test into src/interfaces/libpq.
I did 0001 and 0002 in that order because prove errors out with a stacktrace
if no tap tests exist... It might make more sense to commit them together, but
for review it's easier to keep them separate I think.
Andrew, do you have an idea about the feasibility of supporting any of this
with the msvc build?
I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
coverage, because it already doesn't build the test. Once we've ironed that
stuff out, we could do 0003?
Greetings,
Andres Freund
Attachments:
On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
One annoying bit is that our current tap invocation infrastructure for msvc
won't know how to deal with that. We put the build directory containing t/
onto PATH, but that won't work for test/. But we also don't want to install
test binaries. Not sure what the solution for that is.
Would it help if the C executable, not Perl, was the thing actually
producing the TAP output? The binaries built from test/ could be placed
into t/. Or does that just open up a new set of problems?
--Jacob
Hi,
On 2022-02-24 17:03:33 +0000, Jacob Champion wrote:
On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
One annoying bit is that our current tap invocation infrastructure for msvc
won't know how to deal with that. We put the build directory containing t/
onto PATH, but that won't work for test/. But we also don't want to install
test binaries. Not sure what the solution for that is.Would it help if the C executable, not Perl, was the thing actually
producing the TAP output? The binaries built from test/ could be placed
into t/. Or does that just open up a new set of problems?
I don't think it would help that much. And for the libpq pipeline test it
doesn't really make sense anyway, because we intentionally use it with
different traces and such.
I've thought about a few C tap tests that I'd like, but I think that's a
separate discussion.
Greetings,
Andres Freund
On 24.02.22 16:17, Tom Lane wrote:
I think that having t/ directories contain only Perl test scripts
is a good convention that we should stick to. Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.
I wonder if there are any conventions in the Perl community about where
to put test support files relative to the "t" directory.
Hi,
On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
coverage, because it already doesn't build the test. Once we've ironed that
stuff out, we could do 0003?
From what I can see in the buildfarm client, we'd not loose (nor gain) any
buildfarm coverage either. It doesn't run the test today.
Greetings,
Andres Freund
Hi,
On 2022-02-25 09:56:47 -0800, Andres Freund wrote:
On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
coverage, because it already doesn't build the test. Once we've ironed that
stuff out, we could do 0003?From what I can see in the buildfarm client, we'd not loose (nor gain) any
buildfarm coverage either. It doesn't run the test today.
Attached are rebased patches. I polished 0001, the regress.pl -> 001_uri.pl
conversion some more (although some of perltidy's changes aren't clearly an
improvement).
I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
Greetings,
Andres Freund
Attachments:
Hi,
On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
Pushed. Attached is the remainder, 0003, the move of libpq_pipeline to
src/interfaces/libpq that I'm not planning to push for now.
Regards,
Andres
Attachments:
On 2/24/22 07:19, Andrew Dunstan wrote:
On 2/23/22 20:52, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
libpq TAP tests should be in src/interfaces/libpq/t/.
That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.Such things could be put under src/interfaces/libpq/test, or some other
subdirectory. We already have src/interfaces/ecpg/test.OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said. I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.It won't without some adjustment.
See
<https://github.com/PGBuildFarm/client-code/commit/ffc0fc029877632e9437af51bd99ace308daf0c8>
and
<https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2022-03-01%2010%3A47%3A22&stg=module-libpq-check>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Hi,
On March 1, 2022 7:44:27 AM PST, Andrew Dunstan <andrew@dunslane.net> wrote:
On 2/24/22 07:19, Andrew Dunstan wrote:
On 2/23/22 20:52, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
libpq TAP tests should be in src/interfaces/libpq/t/.
That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.Such things could be put under src/interfaces/libpq/test, or some other
subdirectory. We already have src/interfaces/ecpg/test.OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said. I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.It won't without some adjustment.
See
<https://github.com/PGBuildFarm/client-code/commit/ffc0fc029877632e9437af51bd99ace308daf0c8>
and
<https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2022-03-01%2010%3A47%3A22&stg=module-libpq-check>
Thanks!
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
Pushed. Attached is the remainder, 0003, the move of libpq_pipeline to
src/interfaces/libpq that I'm not planning to push for now.
I saw that Andrew just pushed something to start building this under MSVC.
In case it's of any interest, I had done this differently a while back.
This probably doesn't apply except on top of some other patches, but you get
the idea.
commit 923f8a1c2cbea35cb01d1599caa2a81e3186181c
Author: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Mon Feb 28 01:31:10 2022 -0600
f!
ci-os-only: windows
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 4364ab943fd..71ec747e544 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -44,6 +44,7 @@ my $contrib_extraincludes = {};
my $contrib_extrasource = {
'uri-regress' => ['src/interfaces/libpq/test/uri-regress.c'],
'testclient' => ['src/interfaces/libpq/test/testclient.c'],
+ 'libpq_pipeline' => ['src/interfaces/libpq/test/libpq_pipeline.c'],
};
my @contrib_excludes = (
'bool_plperl', 'commit_ts',
@@ -475,7 +476,7 @@ sub mkvcbuild
push @contrib_excludes, 'uuid-ossp';
}- foreach my $subdir ('contrib', 'src/test/modules', 'src/interfaces/libpq')
+ foreach my $subdir ('contrib', 'src/test/modules') #, 'src/interfaces/libpq')
{
opendir($D, $subdir) || croak "Could not opendir on $subdir!\n";
while (my $d = readdir($D))
@@ -804,6 +805,20 @@ sub mkvcbuild
$p->AddReference($postgres);
}+ $mf = Project::read_file('src/interfaces/libpq/test/Makefile');
+ $mf =~ s{\\\r?\n}{}g;
+ $mf =~ m{PROGRAMS\s*=\s*(.*)$}m
+ || die 'Could not match in src/interfaces/libpq/test/Makefile' . "\n";
+ foreach my $prg (split /\s+/, $1)
+ {
+ my $proj = $solution->AddProject($prg, 'exe', 'bin');
+ $proj->AddFile("src/interfaces/libpq/test/$prg.c"); # implicit source file
+ $proj->AddIncludeDir('src/interfaces/libpq');
+ # XXX: pipeline needs pgcommon and ws2, but uri-regress doesn't
+ $proj->AddReference($libpq, $libpgport, $libpgcommon);
+ $proj->AddLibrary('ws2_32.lib');
+ }
+
$mf = Project::read_file('src/bin/scripts/Makefile');
$mf =~ s{\\\r?\n}{}g;
$mf =~ m{PROGRAMS\s*=\s*(.*)$}mOn 2022-04-16 Sa 10:44, Justin Pryzby wrote:
On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
Pushed. Attached is the remainder, 0003, the move of libpq_pipeline to
src/interfaces/libpq that I'm not planning to push for now.I saw that Andrew just pushed something to start building this under MSVC.
In case it's of any interest, I had done this differently a while back.
This probably doesn't apply except on top of some other patches, but you get
the idea.
I think what I have committed should be quite adequate for now. Once we
get to building with meson a lot of this ugliness should go away.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
Pushed.
If I'm not wrong, this isn't being run by check-world.
commit 4dc465207517c4b69a1f2b657a8ad0700c08e34c
Author: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat May 28 22:32:58 2022 -0500
libpq tests were not being run
See also:
ac25173cdbc40b310a7e72d9557c45a699f1f7b3
6b04abdfc5e0653542ac5d586e639185a8c61a39
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 2352fc1171a..cb613086c7c 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -68,10 +68,10 @@ check check-tests installcheck installcheck-parallel installcheck-tests: CHECKPR
check check-tests installcheck installcheck-parallel installcheck-tests: submake-generated-headers
$(MAKE) -C src/test/regress $@-$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib src/bin,check)
-$(call recurse,checkprep, src/test src/pl src/interfaces/ecpg contrib src/bin)
+$(call recurse,check-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,check)
+$(call recurse,checkprep, src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin)-$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib src/bin,installcheck)
+$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,installcheck)
$(call recurse,install-tests,src/test/regress,install-tests)GNUmakefile: GNUmakefile.in $(top_builddir)/config.status
On Sun, May 29, 2022 at 10:18:50AM -0500, Justin Pryzby wrote:
On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
Pushed.
If I'm not wrong, this isn't being run by check-world.
You are right.
-$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib src/bin,check) -$(call recurse,checkprep, src/test src/pl src/interfaces/ecpg contrib src/bin) +$(call recurse,check-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,check) +$(call recurse,checkprep, src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin)-$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib src/bin,installcheck) +$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,installcheck) $(call recurse,install-tests,src/test/regress,install-tests)
Why don't you just use src/interfaces/ instead of adding a direct
path to libpq?
--
Michael
On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
Why don't you just use src/interfaces/ instead of adding a direct
path to libpq?
So, this leads to something like the attached. Does that sound fine
to you?
--
Michael
Attachments:
Hi,
On 2022-05-29 10:18:50 -0500, Justin Pryzby wrote:
On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
Pushed.
If I'm not wrong, this isn't being run by check-world.
Oops, yes. Thanks for catching!
Hi,
On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
Why don't you just use src/interfaces/ instead of adding a direct
path to libpq?So, this leads to something like the attached. Does that sound fine
to you?
That looks reasonable to me. Do you want to apply it or will you?
Regards,
Andres
On Thu, Jun 02, 2022 at 09:48:25AM -0700, Andres Freund wrote:
On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
So, this leads to something like the attached. Does that sound fine
to you?That looks reasonable to me. Do you want to apply it or will you?
Thanks for double-checking! I should be able to take care of that
today.
--
Michael