Re: [dpdk-dev] [PATCH v3 6/7] build: standardize component names and defines

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Oct 15, 2020 at 11:30:29AM +0100, Luca Boccassi wrote:
> On Wed, 2020-10-14 at 15:13 +0100, Bruce Richardson wrote:
> > As discussed on the dpdk-dev mailing list[1], we can make some easy
> > improvements in standardizing the naming of the various components in DPDK,
> > and their associated feature-enabled macros.
> > 
> > Following this patch, each library will have the name in format,
> > 'librte_<name>.so', and the macro indicating that library is enabled in the
> > build will have the form 'RTE_LIB_<NAME>'.
> > 
> > Similarly, for libraries, the equivalent name formats and macros are:
> > 'librte_<class>_<name>.so' and 'RTE_<CLASS>_<NAME>', where class is the
> > device type taken from the relevant driver subdirectory name, i.e. 'net',
> > 'crypto' etc.
> > 
> > To avoid too many changes at once for end applications, the old macro names
> > will still be provided in the build in this release, but will be removed
> > subsequently.
> > 
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > 
> > [1] http://inbox.dpdk.org/dev/ef7c1a87-79ab-e405-4202-39b7ad6b0c71@solarflare.com/t/#u
> > ---
> >  app/test-bbdev/meson.build            |  4 ++--
> >  app/test-crypto-perf/meson.build      |  2 +-
> >  app/test-pmd/meson.build              | 12 ++++++------
> >  app/test/meson.build                  |  8 ++++----
> >  doc/guides/rel_notes/deprecation.rst  |  8 ++++++++
> >  drivers/baseband/meson.build          |  1 -
> >  drivers/bus/meson.build               |  1 -
> >  drivers/common/meson.build            |  1 -
> >  drivers/common/mlx5/meson.build       |  1 -
> >  drivers/common/qat/meson.build        |  1 -
> >  drivers/compress/meson.build          |  1 -
> >  drivers/compress/octeontx/meson.build |  2 +-
> >  drivers/crypto/meson.build            |  1 -
> >  drivers/crypto/null/meson.build       |  2 +-
> >  drivers/crypto/octeontx/meson.build   |  2 +-
> >  drivers/crypto/octeontx2/meson.build  |  2 +-
> >  drivers/crypto/scheduler/meson.build  |  2 +-
> >  drivers/crypto/virtio/meson.build     |  2 +-
> >  drivers/event/dpaa/meson.build        |  2 +-
> >  drivers/event/dpaa2/meson.build       |  2 +-
> >  drivers/event/meson.build             |  1 -
> >  drivers/event/octeontx/meson.build    |  2 +-
> >  drivers/event/octeontx2/meson.build   |  2 +-
> >  drivers/mempool/meson.build           |  1 -
> >  drivers/meson.build                   |  9 ++++-----
> >  drivers/net/meson.build               |  1 -
> >  drivers/net/mlx4/meson.build          |  2 +-
> >  drivers/raw/ifpga/meson.build         |  2 +-
> >  drivers/raw/meson.build               |  1 -
> >  drivers/regex/meson.build             |  1 -
> >  drivers/vdpa/meson.build              |  1 -
> >  examples/bond/meson.build             |  2 +-
> >  examples/ethtool/meson.build          |  2 +-
> >  examples/ioat/meson.build             |  2 +-
> >  examples/l2fwd-crypto/meson.build     |  2 +-
> >  examples/ntb/meson.build              |  2 +-
> >  examples/vm_power_manager/meson.build |  6 +++---
> >  lib/librte_ethdev/meson.build         |  1 -
> >  lib/librte_graph/meson.build          |  2 --
> >  lib/meson.build                       |  3 ++-
> >  40 files changed, 47 insertions(+), 55 deletions(-)
> 
> Does this change the share object file names too, or only the macros?
>

It does indeed change the object name files, which is a little bit
concerning. However, the consensus based on the RFC seemed to be that the
benefit is likely worth the change. If we want, we can look to use symlinks
to the old names on install, but I think that just delays the pain since I
would expect few to actually change their build to the new names until the
old ones and the symlinks completely go away.

/Bruce