On Thu, 2020-10-15 at 15:03 +0100, Bruce Richardson wrote: > 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.richard...@intel.com> > > > > > > > > > > [1] > > > > > http://inbox.dpdk.org/dev/ef7c1a87-79ab-e405-4202-39b7ad6b0...@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
Ok that makes sense, I wasn't sure if this series was targeted for 20.11 or for later. In that case, Acked-by: Luca Boccassi <bl...@debian.org> -- Kind regards, Luca Boccassi
