Re: [RFC] building postgres with meson - v11

Hi,

On Wed, Aug 31, 2022 at 1:42 AM Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)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.
>