[dpdk-dev] [PATCH v3 22/37] doc: remove references to make in contributing guides

[Thomas Monjalon]

On Thu Sep 3, 2020 at 6:27 PM CEST, Ciara Power wrote:
> --- a/doc/guides/contributing/coding_style.rst
> +++ b/doc/guides/contributing/coding_style.rst
> -DPDK supports being built in two different ways:
> -
> -* using ``make`` - or more specifically "GNU make", i.e. ``gmake`` on
> FreeBSD
> -* using the tools ``meson`` and ``ninja``
> +DPDK supports being built by using the tools ``meson`` and ``ninja``

We can simply say "DPDK *is* built".
I will add a final dot at the end of the sentence.

> Any new library or driver to be integrated into DPDK should support
> being
> -built with both systems. While building using ``make`` is a legacy
> approach, and
> -most build-system enhancements are being done using ``meson`` and
> ``ninja``
> -there are no plans at this time to deprecate the legacy ``make`` build
> system.
> +built with this system.

I think this paragraph does not make sense anymore.

> -Therefore all new component additions should include both a
> ``Makefile`` and a
> -``meson.build`` file, and should be added to the component lists in
> both the
> -``Makefile`` and ``meson.build`` files in the relevant top-level
> directory:
> +Therefore all new component additions should include a ``meson.build``
> file,
> +and should be added to the component lists in the ``meson.build`` files
> in the
> +relevant top-level directory:
> either ``lib`` directory or a ``driver`` subdirectory.
[...]
> --- a/doc/guides/contributing/design.rst
> +++ b/doc/guides/contributing/design.rst
> When absolutely necessary, there are several ways to handle specific
> code:
>  
> -* Use a ``#ifdef`` with the CONFIG option in the C code.
> +* Use a ``#ifdef`` with a build definition macro in the C code.
> This can be done when the differences are small and they can be embedded
> in the same C file:
>  
> .. code-block:: c
> @@ -32,30 +32,22 @@ When absolutely necessary, there are several ways to
> handle specific code:
> titi();
> #endif
>  
> -* Use the CONFIG option in the Makefile. This is done when the
> differences are more significant.
> - In this case, the code is split into two separate files that are
> architecture or environment specific.
> - This should only apply inside the EAL library.

If removing this last item, there are no "several ways" anymore.
I think we should keep it (reworded) because we still have
files compiled depending on the target architecture.

[...]
> -Library Statistics
> -------------------
> -
> -Description
> -~~~~~~~~~~~
> -
> -This document describes the guidelines for DPDK library-level
> statistics counter
> -support. This includes guidelines for turning library statistics on and
> off and
> -requirements for preventing ABI changes when implementing statistics.

I think the ABI part is still relevant.

[...]
> -Prevention of ABI changes due to library statistics support
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> -
> -The layout of data structures and prototype of functions that are part
> of the
> -library API should not be affected by whether the collection of
> statistics
> -counters is turned on or off for the current library. In practical
> terms, this
> -means that space should always be allocated in the API data structures
> for
> -statistics counters and the statistics related API functions are always
> built
> -into the code, regardless of whether the statistics counter collection
> is turned
> -on or off for the current library.
> -
> -When the collection of statistics counters for the current library is
> turned
> -off, the counters retrieved through the statistics related API
> functions should
> -have a default value of zero.