Re: Meson far from ready on Windows

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Meson far from ready on Windows
Дата
Msg-id CA+OCxoxXkTziDGAgU=hHMWTQ07YiohLXr_bFeCGX6-7s0SO3Xw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Meson far from ready on Windows  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Meson far from ready on Windows
Список pgsql-hackers


On Fri, 21 Jun 2024 at 16:15, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Jun 21, 2024 at 7:21 AM Dave Page <dpage@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_VMJcerM1Cs_@paquier.xyz
http://postgr.es/m/20230408191007.7lysd42euafwl74f@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.
 
--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: improve predefined roles documentation
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: New standby_slot_names GUC in PG 17