Hi On Wed, 6 Nov 2024 at 16:11, Peter Eisentraut <pe...@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.
