Re: [RFC] building postgres with meson - v11 - Mailing list pgsql-hackers
| From | samay sharma |
|---|---|
| Subject | Re: [RFC] building postgres with meson - v11 |
| Date | |
| Msg-id | CAJxrbyw8ooBXrDTjkLA1XHMRu5uWsvfupwAWwknMV2qX3L1WYg@mail.gmail.com Whole thread Raw |
| In response to | Re: [RFC] building postgres with meson - v11 (samay sharma <smilingsamay@gmail.com>) |
| Responses |
Re: [RFC] building postgres with meson - v11
|
| List | pgsql-hackers |
On Thu, Sep 1, 2022 at 4:12 PM samay sharma <smilingsamay@gmail.com> wrote:
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 NotesI 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 notesIt 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.
Another thing I'd like input on. A common question I've heard from people who've tried out the docs is How do we do the equivalent of X in make with meson. As meson will be new for a bunch of people who are fluent with make, I won't be surprised if this is a common ask. To address that, I was planning to add a page to specify the key things one needs to keep in mind while "migrating" from make to meson and having a translation table of commonly used commands.
I was planning to add it in the meson section, but if we go ahead with the structure proposed above, it doesn't fit it into one as cleanly. Maybe, it still goes in the meson section? Thoughts?
Regards,
Samay
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.
pgsql-hackers by date: