Horton

Re: [RFC] building postgres with meson - v11

samay sharma <smilingsamay@gmail.com>

View thread View on postgr.es
From: samay sharma <smilingsamay@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: 2022-09-01T23:12:14Z
Lists: pgsql-hackers 
Hi,

On Wed, Aug 31, 2022 at 1:42 AM Peter Eisentraut <
peter.eisentraut@enterprisedb.com> wrote:

> On 24.08.22 17:30, Andres Freund wrote:
> >> 0545eec895 meson: Add docs
> >>
> >> We should think more about how to arrange the documentation.  We
> >> probably don't want to copy-and-paste all the introductory and
> >> requirements information.  I think we can make this initially much
> >> briefer, like the Windows installation chapter.  For example, instead
> >> of documenting each setup option again, just mention which ones exist
> >> and then point (link) to the configure chapter for details.
> > The current docs, including the windows ones, are already hard to
> follow. I
> > think we should take some care to not make the meson bits even more
> > confusing. Cross referencing left and right seems problematic from that
> angle.
>
> If you look at the current structure of the installation chapter
>
> 17.1. Short Version
> 17.2. Requirements
> 17.3. Getting the Source
> 17.4. Installation Procedure
> 17.5. Post-Installation Setup
> 17.6. Supported Platforms
> 17.7. Platform-Specific Notes
>
> only 17.1, small parts of 12.2, and 17.4 should differ between make and
> meson.  There is no conceivable reason why the meson installation
> chapter should have a different "Getting the Source" section.  And some
> of the post-installation and platform-specific information doesn't
> appear at all on the meson chapter.
>
> I think we can try to be a bit more ingenious in how we weave this
> together in the best way.  What I really wouldn't want is two separate
> chapters that duplicate the entire process.  I think we could do one
> chapter, like
>
> - Short Version
> - Requirements
> - Getting the Source
> - Installation Procedure
> - Installation Procedure using Meson
> - Post-Installation Setup
> - Supported Platforms
> - Platform-Specific Notes
>

I spent some more time thinking about the structure of the docs. The
getting the source, supported platforms, post installation setup and
platform specific notes sections are going to be mostly common. We do
expect some differences in supported platforms and platform specific notes
but I think they should be manageable without confusing readers.

The others; short version, requirements, and installation procedure are
pretty different and I feel combining them will end up confusing readers or
require creating autoconf / make and meson versions of many things at many
different places. Also, if we keep it separate, it'll be easier to remove
make / autoconf specific sections if (when?) we want to do that.

So, I was thinking of the following structure:
- Supported Platforms
- Getting the Source
- Building with make and autoconf
  -- Short version
  -- Requirements
  -- Installation Procedure and it's subsections
- Building with Meson
  -- Short version
  -- Requirements
  -- Installation Procedure and it's subsections
- Post-installation Setup
- Platform specific notes

It has the disadvantage of short version moving to a bit later in the
chapter but I think it's a good structure to reduce duplication and also
keep sections which are different separate. Thoughts on this approach? If
this looks good, I can submit a patch rearranging things this way.

As a follow up patch, we could also try to fit the Windows part into this
model. We could add a Building with visual C++ or Microsoft windows SDK
section. It doesn't have a short version but follows the remaining template
of requirements and installation procedure subsections (Building, Cleaning
and Installing and Running Regression tests) well.

Regards,
Samay

>
> Alternatively, if people prefer two separate chapters, let's think about
> some source-code level techniques to share the common contents.
>

Commits

  1. meson: Add 'running' test setup, as a replacement for installcheck

  2. meson: Add support for building with precompiled headers

  3. windows: Adjust FD_SETSIZE via commandline define

  4. meson: docs: Add xml{lint,proc} wrapper to collect dependencies

  5. meson: ecpg: Split definition of static and shared libraries

  6. windows: Set UMDF_USING_NTSTATUS globally, include ntstatus.h

  7. ci: Add hint about downloadable logs to README

  8. meson: Set up absolute rpaths to libdir

  9. meson: Include CFLAGS/c_args in summary and pg_config output

  10. windows: remove date from version number in win32ver.rc

  11. meson: Add initial version of meson based build system

  12. ci: windows: set error mode to not include SEM_NOGPFAULTERRORBOX

  13. Refactor PG_TEST_EXTRA logic in autoconf build

  14. Split TESTDIR into TESTLOGDIR and TESTDATADIR

  15. Don't hardcode tmp_check/ as test directory for tap tests

  16. Extend gendef.pl in preparation for meson

  17. Include c.h instead of postgres.h in src/port/*p{read,write}*.c

  18. Remove DLLTOOL, DLLWRAP from configure / Makefile.global.in

  19. Run xmllint validation only once

  20. Bump minimum Perl version to 5.14

  21. Move gramparse.h to src/backend/parser

  22. Run perltidy over Catalog.pm

  23. Parse catalog .dat files as a whole when compiling the backend

  24. Build all Flex files standalone

  25. Move private declarations shared between guc.c and guc-file.l to new header

  26. Preparatory refactoring for compiling guc-file.c standalone

  27. Move darwin sysroot determination into separate file

  28. Fix MSVC warning in compat_informix/rnull.pgc

  29. solaris: Use versioning scripts instead of -Bsymbolic

  30. Change shared library installation naming on macOS

  31. regress: allow to specify directory containing expected files, for ecpg

  32. Don't add HAVE_LDAP_H HAVE_WINLDAP_H to pg_config.h

  33. Refactor dtrace postprocessing make rules

  34. Add output directory option to gen_node_support.pl

  35. Add output directory argument to generate-unicode_norm_table.pl

  36. Add output file argument to generate-errcodes.pl

  37. Add output path arg in generate-lwlocknames.pl

  38. Move snowball_create.sql creation into perl file

  39. ecpg: Output dir, source dir, stamp file argument for preproc/*.pl

  40. psql: Output dir and dependency generation for sql_help

  41. Deal with paths containing \ and spaces in basebackup_to_shell tests

  42. Remove LLVM_CONFIG from Makefile.global.in

  43. Make update-unicode target work in vpath builds

  44. Refactor DLSUFFIX handling

  45. ldap tests: Add paths for openbsd.

  46. ldap tests: Don't run on unsupported operating systems.

  47. Remove check for accept() argument types

  48. Move our p{read,write}v replacements into their own files.

  49. Adjust yywrap macro for non-reentrant scanners for MSVC.

  50. Remove any -arch switches given in ExtUtils::Embed's ldopts from our

  51. Change PL/Perl and Pg interface build to use configured compiler and

  52. Apparently, on some systems, ExtUtils::Embed and MakeMaker are slightly