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'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.
