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 02:05:37PM +0100, Luca Boccassi wrote:
> On Thu, 2020-10-15 at 12:18 +0100, Bruce Richardson wrote:
> > 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
> 
> It is a backward incompatible change, so we need to provide symlinks,
> right? On upgrade, programs linked to librte_old.so will fail to start.
> Or was this targeted at 20.11 thus piggy-backing on the ABI change
> which forces a re-link?
> 
More of the latter, and the fact that changing the build system involved a
few library renames anyway for those using make. Since the ABI is changing
this release, and all the libs have a new major version number there is no
requirement for libs linked against an older version to work, and since
pkg-config should now be used for linking the actual names should not be
a concern.

That's the thinking anyway. :-)

/Bruce