Horton

Thread

Commits

  1. Add win32ver data to meson-built postgres.exe.

  2. Give postgres.exe the icon of other executables.

  1. win32ver data in meson-built postgres.exe

    Noah Misch <noah@leadboat.com> — 2023-06-07T23:14:07Z

    A postgres.exe built with meson, ninja, and MSVC lacks the version metadata
that postgres.exe gets under non-meson build systems.  Patch attached.

  2. Re: win32ver data in meson-built postgres.exe

    Andres Freund <andres@anarazel.de> — 2023-06-07T23:47:26Z

    Hi,

On 2023-06-07 16:14:07 -0700, Noah Misch wrote:
> A postgres.exe built with meson, ninja, and MSVC lacks the version metadata
> that postgres.exe gets under non-meson build systems.  Patch attached.

I dimly recall that we discussed that and basically decided that it doesn't
really make sense to attach this information to postgres.exe.


>     This preserves two quirks of the older build systems.  First,
>     postgres.exe is icon-free.

We could also just change that.


>     Second, the resources object is not an input
>     to postgres.def.

I don't see what negative effects that could have: postgres.def is used to
provide symbol "thunks" to extension libraries, which don't need to access
this information.  If we used the rc compiler to inject binary data (say
bootstrap.bki) into binaries, it'd possibly be a different story (although I
think it might work anyway) - but if we wanted to do something like that, we'd
build portable infrastructure anyway.


> -  rcgen_bin_args = rcgen_base_args + [
> +  rcgen_server_args = rcgen_base_args + [
>      '--VFT_TYPE', 'VFT_APP',
> -    '--FILEENDING', 'exe',
> +    '--FILEENDING', 'exe'
> +  ]
> +
> +  rcgen_bin_args = rcgen_server_args + [
>      '--ICO', pg_ico
>    ]

Somehow it seems a bit wrong to derive non-server from server, but ... ;)


Greetings,

Andres Freund

  3. Re: win32ver data in meson-built postgres.exe

    Noah Misch <noah@leadboat.com> — 2023-06-08T01:45:07Z

    On Wed, Jun 07, 2023 at 04:47:26PM -0700, Andres Freund wrote:
> On 2023-06-07 16:14:07 -0700, Noah Misch wrote:
> > A postgres.exe built with meson, ninja, and MSVC lacks the version metadata
> > that postgres.exe gets under non-meson build systems.  Patch attached.
> 
> I dimly recall that we discussed that and basically decided that it doesn't
> really make sense to attach this information to postgres.exe.

I looked for a discussion behind that, but I didn't find it.  A key
user-visible consequence is whether the task manager "Name" column shows (1)
"PostgreSQL Server" (version data present) vs. (2) "postgres.exe" (no version
data).  While (2) is not terrible, (1) is more typical on Windows.  I don't
see cause to migrate to (2) after N years of sending (1).  Certainly this part
of the user experience should not depend on one's choice of build system.

> >     This preserves two quirks of the older build systems.  First,
> >     postgres.exe is icon-free.
> 
> We could also just change that.

I would be +1 for that (only if done for all build systems).  Showing the
elephant in task manager feels better than showing the generic-exe icon.

> >     Second, the resources object is not an input
> >     to postgres.def.
> 
> I don't see what negative effects that could have:

Agreed.  I wrote that sentence for archaeologists of the future who might
wonder why this change didn't use generated_backend_sources.

  4. Re: win32ver data in meson-built postgres.exe

    Magnus Hagander <magnus@hagander.net> — 2023-06-08T11:10:00Z

    On Thu, Jun 8, 2023 at 3:45 AM Noah Misch <noah@leadboat.com> wrote:
>
> On Wed, Jun 07, 2023 at 04:47:26PM -0700, Andres Freund wrote:
> > On 2023-06-07 16:14:07 -0700, Noah Misch wrote:
> > > A postgres.exe built with meson, ninja, and MSVC lacks the version metadata
> > > that postgres.exe gets under non-meson build systems.  Patch attached.
> >
> > I dimly recall that we discussed that and basically decided that it doesn't
> > really make sense to attach this information to postgres.exe.
>
> I looked for a discussion behind that, but I didn't find it.  A key
> user-visible consequence is whether the task manager "Name" column shows (1)
> "PostgreSQL Server" (version data present) vs. (2) "postgres.exe" (no version
> data).  While (2) is not terrible, (1) is more typical on Windows.  I don't
> see cause to migrate to (2) after N years of sending (1).  Certainly this part
> of the user experience should not depend on one's choice of build system.

+1, both on that it should be the same across build systems, and that
the variant that we have in the msvc build system is the best one.

And if we don't have the version structure in it, it will cause issues
for installers (I think) and software inventory processes (definitely)
that also use that.

I don't recall a discussion about removing it, but it's not unlikely I
missed it if it did take place...


> > >     This preserves two quirks of the older build systems.  First,
> > >     postgres.exe is icon-free.
> >
> > We could also just change that.
>
> I would be +1 for that (only if done for all build systems).  Showing the
> elephant in task manager feels better than showing the generic-exe icon.

I think this decision goes back all the way to the ancient times, and
the argument was then "user should not use the postgres.exe file when
clicking around" sort of. Back then, task manager didn't show the icon
at all, regardless. It does now, so I'm +1 to add the icon (in all the
build systems).

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

  5. Re: win32ver data in meson-built postgres.exe

    Andres Freund <andres@anarazel.de> — 2023-06-09T17:45:27Z

    Hi,

On 2023-06-07 18:45:07 -0700, Noah Misch wrote:
> On Wed, Jun 07, 2023 at 04:47:26PM -0700, Andres Freund wrote:
> > On 2023-06-07 16:14:07 -0700, Noah Misch wrote:
> > > A postgres.exe built with meson, ninja, and MSVC lacks the version metadata
> > > that postgres.exe gets under non-meson build systems.  Patch attached.
> >
> > I dimly recall that we discussed that and basically decided that it doesn't
> > really make sense to attach this information to postgres.exe.
>
> I looked for a discussion behind that, but I didn't find it.  A key
> user-visible consequence is whether the task manager "Name" column shows (1)
> "PostgreSQL Server" (version data present) vs. (2) "postgres.exe" (no version
> data).  While (2) is not terrible, (1) is more typical on Windows.  I don't
> see cause to migrate to (2) after N years of sending (1).  Certainly this part
> of the user experience should not depend on one's choice of build system.

I think I misremembered some details... I guess I was remembering the icon for
dlls, in
https://postgr.es/m/20220829221314.pepagj3i5mj43niy%40awork3.anarazel.de

Touching the rc stuff always makes me feel dirty enough that I want to swap it
out of my brain, if not run some deep erase tool :)


> > >     This preserves two quirks of the older build systems.  First,
> > >     postgres.exe is icon-free.
> >
> > We could also just change that.
>
> I would be +1 for that (only if done for all build systems).  Showing the
> elephant in task manager feels better than showing the generic-exe icon.

Let's do that then.

Greetings,

Andres Freund

  6. Re: win32ver data in meson-built postgres.exe

    Noah Misch <noah@leadboat.com> — 2023-06-09T20:14:55Z

    On Thu, Jun 08, 2023 at 01:10:00PM +0200, Magnus Hagander wrote:
> On Thu, Jun 8, 2023 at 3:45 AM Noah Misch <noah@leadboat.com> wrote:
> > On Wed, Jun 07, 2023 at 04:47:26PM -0700, Andres Freund wrote:
> > > On 2023-06-07 16:14:07 -0700, Noah Misch wrote:
> > > >     postgres.exe is icon-free.
> > >
> > > We could also just change that.
> >
> > I would be +1 for that (only if done for all build systems).  Showing the
> > elephant in task manager feels better than showing the generic-exe icon.
> 
> I think this decision goes back all the way to the ancient times, and
> the argument was then "user should not use the postgres.exe file when
> clicking around" sort of. Back then, task manager didn't show the icon
> at all, regardless. It does now, so I'm +1 to add the icon (in all the
> build systems).

That sounds good, and it's the attached one-byte change.  That also simplifies
the Meson fix; new version attached.