Thread: Re: doc: pgevent.dll location
On Mon, Nov 4, 2024 at 7:02 PM Ryohei Takahashi (Fujitsu) <r.takahashi_2@fujitsu.com> wrote: > > On the other hand, pgevent.dll is moved from lib/ directory to bin/directory on PG 17.0 > > (It seems that it is moved because of meson) > > So, I think the documentation need to be updated like attached. I'm unable to confirm the veracity of the claim that the pgevent.dll file on Windows is now placed in a different directory, and that this is a result of meson builds. But the patch looks good to me; it applies cleanly to REL_17_STABLE and main branches. Best regards, Gurjeet http://Gurje.et
On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh <gurjeet@singh.im> wrote: > I'm unable to confirm the veracity of the claim that the pgevent.dll > file on Windows is now placed in a different directory, and that this > is a result of meson builds. But the patch looks good to me; it > applies cleanly to REL_17_STABLE and main branches. I think we will need to find someone who can confirm whether or not the claim is correct. -- Robert Haas EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh <gurjeet@singh.im> wrote:
>> I'm unable to confirm the veracity of the claim that the pgevent.dll
>> file on Windows is now placed in a different directory, and that this
>> is a result of meson builds. But the patch looks good to me; it
>> applies cleanly to REL_17_STABLE and main branches.
> I think we will need to find someone who can confirm whether or not
> the claim is correct.
More to the point: if that does happen, isn't it a bug to be fixed
rather than documented?
regards, tom lane
On Tue, 5 Nov 2024 at 15:10, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh <gurjeet@singh.im> wrote:
> I'm unable to confirm the veracity of the claim that the pgevent.dll
> file on Windows is now placed in a different directory, and that this
> is a result of meson builds. But the patch looks good to me; it
> applies cleanly to REL_17_STABLE and main branches.
I think we will need to find someone who can confirm whether or not
the claim is correct.
It is correct. In v16, it was in lib/, in v17, bin/.
However, on Windows I think it probably makes (marginally) more sense to include it in bin/ - we already have other libraries in there that are linked at compile time. pgevent is something of a special case, but it's probably more similar to those libraries than the extensions etc. that are in lib/.
Related sidenote: I got a complaint today that pg_regress.exe is no longer part of the Windows installation footprint - and indeed, it's not installed at all with Meson builds, which is problematic for those doing CI/CD testing of extensions.
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
Hi, Thank you for your reply. The dll install paths are changed as follows on Windows. (1) pgevent.dll PG16: lib/ PG17: bin/ (2) dll for user (like libpq.dll, libecpg.dll) PG16: Both in lib/ and bin/ PG17: bin/ (3) contrib dll (like amcheck.dll) PG16: lib/ PG17: lib/ I understand that Dave says (1) and (2) should exist on bin/ directory and the paths in PG17 are correct. So, I think it is correct to update documentation. Regards, Ryohei Takahashi
On 06.11.24 13:57, Ryohei Takahashi (Fujitsu) wrote: > The dll install paths are changed as follows on Windows. > > (1) pgevent.dll > PG16: lib/ > PG17: bin/ > > (2) dll for user (like libpq.dll, libecpg.dll) > PG16: Both in lib/ and bin/ > PG17: bin/ > > (3) contrib dll (like amcheck.dll) > PG16: lib/ > PG17: lib/ > > > I understand that Dave says (1) and (2) should exist on bin/ directory > and the paths in PG17 are correct. > > So, I think it is correct to update documentation. I don't have Windows handy to test it out, but looking at the respective build system source files, in master, pgevent is built and installed like a normal shared library in both meson.build and Makefile, so it should end up somewhere in lib. In src/tools/msvc in REL_16_STABLE, I see some code that appears to suggest that it installs in bin. Again, this is just reading the code, but it seems to be backwards from what is claimed earlier. The statements like "in PGxxx it did this" are not precise enough because there are three possible build systems. We need to know what each build system is doing. Also, the consideration of consistency should go in two dimensions: Consistency between versions and consistency between build systems.
Hi
On Wed, 6 Nov 2024 at 16:11, Peter Eisentraut <peter@eisentraut.org> wrote:
On 06.11.24 13:57, Ryohei Takahashi (Fujitsu) wrote:
> The dll install paths are changed as follows on Windows.
>
> (1) pgevent.dll
> PG16: lib/
> PG17: bin/
>
> (2) dll for user (like libpq.dll, libecpg.dll)
> PG16: Both in lib/ and bin/
> PG17: bin/
>
> (3) contrib dll (like amcheck.dll)
> PG16: lib/
> PG17: lib/
>
>
> I understand that Dave says (1) and (2) should exist on bin/ directory
> and the paths in PG17 are correct.
>
> So, I think it is correct to update documentation.
I don't have Windows handy to test it out, but looking at the respective
build system source files, in master, pgevent is built and installed
like a normal shared library in both meson.build and Makefile, so it
should end up somewhere in lib.
In src/tools/msvc in REL_16_STABLE, I see some code that appears to
suggest that it installs in bin.
Again, this is just reading the code, but it seems to be backwards from
what is claimed earlier.
I downloaded the builds of v16 and v17 from
https://github.com/dpage/winpgbuild/actions/runs/11639786998, a project worked on by Andres, Dave Cramer, and myself.
I've just double-checked I didn't get mixed up, and can confirm that in v17, pgevent.dll is installed into bin/ and in v16.4, it's in lib/
The statements like "in PGxxx it did this" are not precise enough
because there are three possible build systems. We need to know what
each build system is doing. Also, the consideration of consistency
should go in two dimensions: Consistency between versions and
consistency between build systems.
Yeah, sorry - I tend not to even think about Cygwin or Msys builds as they haven't been used for "official" builds on Windows in many, many years.
The builds I'm testing are MSVC++ using the old perl based build system for v16, and MSVC++ using Meson for v17. You can see exactly how they're done in the Github Action script for the action run above.