Re: [RFC] building postgres with meson -v

[Andres Freund]

Hi,

On 2021-10-31 16:24:48 -0700, Andres Freund wrote:
> - support for building docs.
>   I couldn't get dbtoepub work in a vpath style build, so I changed that
>   to also use pandoc. No idea if anybody uses the epub rules?

combing through various FIXMEs in the meson patch I started to look into docs
again. A few questions / noteworthy points:

- I still haven't gotten dbtoepub to work in vpath style builds (epub
  generation is instead using pandoc). Could somebody using these comment on
  the quality difference?

  We don't seem to offer these for download anywhere...

  Worth noting that dbtoepub takes approximately forever (>25min). Not that
  pandoc is fast, but ...

  Unfortunately pandoc doesn't understand  level stuff. That'd probably
  easy enough to tweak, but ...

- We have logic to change the man section (grep for sqlmansect) for some
  platforms. The only remaining platform is solaris. I'm inclined to not
  implement that.

- I've not implemented the texinfo targets - don't think they're really used?

Greetings,

Andres Freund

Re: [RFC] building postgres with meson -v

[Andres Freund]

Hi,

On 2021-11-10 11:07:02 +0100, Peter Eisentraut wrote:
> On 01.11.21 00:24, Andres Freund wrote:
> > Hi,
> > 
> > Attached is an updated version of the meson patchset.
> 
> Nanoreview:  I think the patch

Thanks for looking!


> Subject: [PATCH v5 11/16] meson: prereq: Handle DLSUFFIX in msvc builds
>  similar to other build envs.
> 
> is good to go.  It's not clear why it's needed in this context, but it seems
> good in general to make these things more consistent.

The way it was set between msvc and other builds is currently inconsistent
between msvc and other builds, by virtue of win32_port.h defining for msvc:

/* Things that exist in MinGW headers, but need to be added to MSVC */
#ifdef _MSC_VER
...
/* Pulled from Makefile.port in MinGW */
#define DLSUFFIX ".dll"


it'd have needed unnecessarily contorted logic to continue setting DLSUFFIX
via commandline for !msvc, given that the the meson stuff is the same for msvc
and !msvc.

Greetings,

Andres Freund

Re: [RFC] building postgres with meson -v

[Peter Eisentraut]

On 01.11.21 00:24, Andres Freund wrote:

Hi,

Attached is an updated version of the meson patchset.


Nanoreview:  I think the patch

Subject: [PATCH v5 11/16] meson: prereq: Handle DLSUFFIX in msvc builds
 similar to other build envs.

is good to go.  It's not clear why it's needed in this context, but it 
seems good in general to make these things more consistent.

Re: [RFC] building postgres with meson -v

[Peter Eisentraut]

On 04.11.21 19:48, Andres Freund wrote:

Probably worth putting this in fairly soon independent of whether anything
happens wrt meson?


OK, done. Let's see what happens. ;-)

Re: [RFC] building postgres with meson -v

[Andres Freund]

Hi,

On 2021-11-04 19:17:05 +0100, Peter Eisentraut wrote:
> On 01.11.21 00:24, Andres Freund wrote:
> > - remaining hardcoded configure tests (e.g. ACCEPT_TYPE_ARG*)
> 
> I think we can get rid of that one.

Oh, nice!

I was somewhat confused by "unsigned int PASCAL" as a type.


> That test originally catered to some strange edge cases where the third
> argument was size_t that was not the same size as int.  That is long gone,
> if it ever really existed.  All systems currently of interest use either
> socklen_t or int, and socklen_t is always int.  (A few build farm animals
> report size_t, but they are all 32-bit.)

> diff --git a/src/include/c.h b/src/include/c.h
> index c8ede08273..7c790f557e 100644
> --- a/src/include/c.h
> +++ b/src/include/c.h
> @@ -408,6 +408,10 @@ typedef unsigned char bool;
>   * 
>   */
>  
> +#ifndef HAVE_SOCKLEN_T
> +typedef socklen_t int;
> +#endif

I'd put this in port.h instead of c.h, or is there a reason not to do so?


Probably worth putting this in fairly soon independent of whether anything
happens wrt meson?

Greetings,

Andres Freund

Re: [RFC] building postgres with meson -v

[Peter Eisentraut]

On 01.11.21 00:24, Andres Freund wrote:

- remaining hardcoded configure tests (e.g. ACCEPT_TYPE_ARG*)


I think we can get rid of that one.

That test originally catered to some strange edge cases where the third 
argument was size_t that was not the same size as int.  That is long 
gone, if it ever really existed.  All systems currently of interest use 
either socklen_t or int, and socklen_t is always int.  (A few build farm 
animals report size_t, but they are all 32-bit.)


I think we can change the code to use socklen_t and add a simple check 
to typedef socklen_t as int if not available.  See attached patch.
>From 6229ba9973134dfb184eb21bc62822d83ba554d8 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut 
Date: Thu, 4 Nov 2021 13:50:25 +0100
Subject: [PATCH] Remove check for accept() argument types

---
 aclocal.m4|  1 -
 config/ac_func_accept_argtypes.m4 | 78 -
 configure | 82 +--
 configure.ac  |  2 +-
 src/backend/libpq/auth.c  |  2 +-
 src/backend/libpq/pqcomm.c|  8 +--
 src/backend/postmaster/pgstat.c   |  4 +-
 src/include/c.h   |  4 ++
 src/include/libpq/pqcomm.h|  2 +-
 src/include/pg_config.h.in| 15 ++
 src/interfaces/libpq/fe-connect.c |  2 +-
 src/port/getpeereid.c |  4 +-
 src/tools/msvc/Solution.pm|  5 +-
 13 files changed, 31 insertions(+), 178 deletions(-)
 delete mode 100644 config/ac_func_accept_argtypes.m4

diff --git a/aclocal.m4 b/aclocal.m4
index 5e22482cd5..58ade65046 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -1,5 +1,4 @@
 dnl aclocal.m4
-m4_include([config/ac_func_accept_argtypes.m4])
 m4_include([config/ax_prog_perl_modules.m4])
 m4_include([config/ax_pthread.m4])
 m4_include([config/c-compiler.m4])
diff --git a/config/ac_func_accept_argtypes.m4 
b/config/ac_func_accept_argtypes.m4
deleted file mode 100644
index 178ef67818..00
--- a/config/ac_func_accept_argtypes.m4
+++ /dev/null
@@ -1,78 +0,0 @@
-# config/ac_func_accept_argtypes.m4
-# This comes from the official Autoconf macro archive at
-# 
-
-
-dnl @synopsis AC_FUNC_ACCEPT_ARGTYPES
-dnl
-dnl Checks the data types of the three arguments to accept(). Results are
-dnl placed into the symbols ACCEPT_TYPE_RETURN and ACCEPT_TYPE_ARG[123],
-dnl consistent with the following example:
-dnl
-dnl   #define ACCEPT_TYPE_RETURN int
-dnl   #define ACCEPT_TYPE_ARG1 int
-dnl   #define ACCEPT_TYPE_ARG2 struct sockaddr *
-dnl   #define ACCEPT_TYPE_ARG3 socklen_t
-dnl
-dnl NOTE: This is just a modified version of the AC_FUNC_SELECT_ARGTYPES
-dnl macro. Credit for that one goes to David MacKenzie et. al.
-dnl
-dnl @version $Id: ac_func_accept_argtypes.m4,v 1.1 1999/12/03 11:29:29 simons 
Exp $
-dnl @author Daniel Richard G. 
-dnl
-
-# PostgreSQL local changes: In the original version ACCEPT_TYPE_ARG3
-# is a pointer type. That's kind of useless because then you can't
-# use the macro to define a corresponding variable. We also make the
-# reasonable(?) assumption that you can use arg3 for getsocktype etc.
-# as well (i.e., anywhere POSIX.2 has socklen_t).
-#
-# arg2 can also be `const' (e.g., RH 4.2). Change the order of tests
-# for arg3 so that `int' is first, in case there is no prototype at all.
-#
-# Solaris 7 and 8 have arg3 as 'void *' (disguised as 'Psocklen_t'
-# which is *not* 'socklen_t *').  If we detect that, then we assume
-# 'int' as the result, because that ought to work best.
-#
-# On Win32, accept() returns 'unsigned int PASCAL'
-# Win64 uses SOCKET for return and arg1
-
-AC_DEFUN([AC_FUNC_ACCEPT_ARGTYPES],
-[AC_MSG_CHECKING([types of arguments for accept()])
- AC_CACHE_VAL(ac_cv_func_accept_return,dnl
- [AC_CACHE_VAL(ac_cv_func_accept_arg1,dnl
-  [AC_CACHE_VAL(ac_cv_func_accept_arg2,dnl
-   [AC_CACHE_VAL(ac_cv_func_accept_arg3,dnl
-[for ac_cv_func_accept_return in 'int' 'SOCKET WSAAPI' 'unsigned int 
PASCAL'; do
-  for ac_cv_func_accept_arg1 in 'int' 'SOCKET' 'unsigned int'; do
-   for ac_cv_func_accept_arg2 in 'struct sockaddr *' 'const struct 
sockaddr *' 'void *'; do
-for ac_cv_func_accept_arg3 in 'int' 'size_t' 'socklen_t' 'unsigned 
int' 'void'; do
- AC_COMPILE_IFELSE([AC_LANG_SOURCE(
-[#include 
-#include 
-extern $ac_cv_func_accept_return accept ($ac_cv_func_accept_arg1, 
$ac_cv_func_accept_arg2, $ac_cv_func_accept_arg3 *);])],
- [ac_not_found=no; break 4], [ac_not_found=yes])
-   done
-  done
- done
-done
-if test "$ac_not_found" = yes; then
-  AC_MSG_ERROR([could not determine argument types])
-fi
-if test "$ac_cv_func_accept_arg3" = "void"; then
-  ac_cv_func_accept_arg3=int
-fi
-])dnl AC_CACHE_VAL
-   ])dnl AC_CACHE_VAL
-  ])dnl AC_CACHE_VAL
- ])dnl AC_CACHE_VAL
- AC_MSG_RESULT([$ac_cv_func_accept_return, $ac_cv_func_accept_arg1, 
$ac_cv_func_accept_arg2,