On Fri, 21 Jun 2024 at 16:15, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Jun 21, 2024 at 7:21 AM Dave Page <dp...@pgadmin.org> wrote: > > My assumption all along was that Meson would replace autoconf etc. > before anything happened with MSVC, precisely because that's the type of > environment all the Postgres devs work in primarily. Instead we seem to > have taken what I think is a flawed approach of entirely replacing the > build system on the platform none of the devs use, whilst leaving the new > system as an experimental option on the platforms it will have had orders > of magnitude more testing. > > > > What makes it worse, is that I don't believe anyone was warned about > such a drastic change. Packagers were told about the git archive changes to > the tarball generation, but that's it (and we've said before, we can't > expect packagers to follow all the activity on -hackers). > > I agree that we should have given a heads up to pgsql-packagers. The > fact that that wasn't done is a mistake, and inconsiderate. At the > same time, I don't quite know who should have done that exactly when. > Note that, while I believe Andres is on pgsql-packagers, many > committers are not, and we have no written guidelines anywhere for > what kinds of changes require notifying pgsql-packagers. > > Previous threads on this issue: > > https://postgr.es/m/zqzp_vmjcerm1...@paquier.xyz > http://postgr.es/m/20230408191007.7lysd42euafwl...@awork3.anarazel.de > > Note that in the second of these threads, which contemplated removing > MSVC for v16, I actually pointed out that if we went that way, we > needed to notify pgsql-packagers ASAP. But, since we didn't do that, > no email was ever sent to pgsql-packagers about this, or at least not > that I can find. That's what I was saying should have been done. I don't think there was a requirement on Andres to tell them that they could use Meson instead. > Still, MSVC support was removed more than six months > ago, so even if somebody didn't see any of the pgsql-hackers > discussion about this, there's been a fair amount of time (and a beta) > for someone to notice that their build process isn't working any more. > It seems a bit weird to me to start complaining about this now. > People noticed when they started prepping for beta1. Then there was a mad rush to get things working under Meson in any way possible. > As a practical matter, I don't think MSVC is coming back. The > buildfarm was already changed over to use meson, and it would be > pretty disruptive to try to re-add buildfarm coverage for a > resurrected MSVC on the eve of beta2. I think we should focus on > improving whatever isn't quite right in meson -- plenty of other > people have also complained about various things there, me included -- > rather than trying to undo over a year's worth of work by lots of > people to get things on Windows switched over to MSVC. > The buildfarm hasn't switched over - it had support added for Meson. If it had been switched, then the older back branches would have gone red. Anyway, that's immaterial - I know the old code isn't coming back now. My motivation for this thread is to get Meson to a usable state on Windows, that doesn't require hacking stuff around for the casual builder moving forwards - and at present, it requires *significantly* more hacking around than it has in many years. The design goals Andres spoke about would clearly be a technical improvement to PostgreSQL, however as we're finding, they rely on the upstream dependencies being built with pkgconfig or cmake files which either doesn't happen at present, or only happens if you happen to build in a certain way, or download from some source that has added them. I'm not sure how to fix that without re-introducing the old hacks in the build system, or extending my side project to add .pc files to all the dependencies it builds. I will almost certainly do that, as it'll give folks a single place where they can download everything they need, and provide a reference on how everything can be built if they want to do it themselves, but on the other hand, it's far from an ideal solution and I'd much prefer if I didn't need to do that at all. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com
