From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: When to drop src/tools/msvc support |
Date: | 2023-04-11 10:58:43 |
Message-ID: | 1d342a44-710e-b302-7e2e-2cfbc53b3998@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-04-11 Tu 04:05, Dave Page wrote:
>
>
> On Tue, 11 Apr 2023 at 08:09, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
> On Tue, Apr 11, 2023 at 12:27 AM Andres Freund
> <andres(at)anarazel(dot)de> wrote:
> >
> > Hi,
> >
> > On 2023-04-10 19:55:35 +0100, Dave Page wrote:
> > > Projects other than the EDB installers use the MSVC build
> system - e.g.
> > > pgAdmin uses it’s own builds of libpq and other tools (psql,
> pg_dump etc)
> > > that are pretty heavily baked into a fully automated build
> system (even the
> > > build servers and all their requirements are baked into Ansible).
> > >
> > > Changing that lot would be non-trivial, though certainly
> possible, and I
> > > suspect we’re not the only ones doing that sort of thing.
> >
> > Do you have a link to the code for that, if it's open? Just to
> get an
> > impression for how hard it'd be to switch over?
>
>
> The pgadmin docs/readme refers to
> https://github.com/pgadmin-org/pgadmin4/tree/master/pkg/win32
>
> It clearly doesn't have the full automation stuff, but appears to have
> the parts about building the postgres dependency.
>
>
> Yeah, that's essentially the manual process, though I haven't tested
> it in a while. The Ansible stuff is not currently public. I suspect
> (or rather, hope) that we can pull in all the additional packages
> required using Chocolatey which shouldn't be too onerous.
>
> Probably my main concern is that the Meson build can use the same
> version of the VC++ compiler that we use (v14), which is carefully
> matched for compatibility with all the various components, just in
> case anything passes CRT pointers around. Python is the one thing we
> don't build ourselves on Windows and the process will build modules
> like gssapi and psycopg (which links with libpq of course), so we're
> basically following what they use.
>
>
For meson you just need to to "pip install meson ninja" in your python
distro and you should be good to go (they will be installed in python's
Scripts directory). Don't use chocolatey to install meson/ninja - I ran
into issues doing that.
AFAICT meson will use whatever version of VC you have installed,
although I have only been testing with VC2019.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2023-04-11 11:10:20 | Re: fairywren exiting in ecpg |
Previous Message | Hayato Kuroda (Fujitsu) | 2023-04-11 10:40:54 | RE: [PoC] pg_upgrade: allow to upgrade publisher node |