meson: compatibility with Debian/Ubuntu
cover meson: compatibility with Debian/Ubuntu
From: Luca Boccassi <[email protected]>
A couple of small fixes are needed in order to make the meson build compatible with Debian and Ubuntu, to avoid breaking backward compatibility for applications that depend on the packages.
Debian and Ubuntu have been shipping a pkg-config file for more than a year, but it is called libdpdk.pc rather than DPDK.pc. A few downstream projects, like OVS and Collectd, have started using it in with the former name.
To avoid breaking compatibility, rename it to libdpdk.pc.
Furthermore, in order to avoid breaking multiarch installability, add an option to let users install arch-specific headers in another subdirectory of the arch-independent ones. The reason is that some of the arch specific ones have the same filename, so there is a clash. The new option, include_subdir_arch, is disabled by default.
Finally a small fix to use the configure includedir rather than an hard-coded path for exec-env and generic headers.
Luca Boccassi (3):
build: rename pkgconfig to libdpdk.pc
build: add optional arch-specific headers install path
build: don't hard-code generic/exec-env install path
config/meson.build | 2 +- lib/librte_eal/bsdapp/eal/meson.build | 2 +- lib/librte_eal/common/include/arch/x86/meson.build | 3 ++- lib/librte_eal/common/include/meson.build | 2 +- lib/librte_eal/linuxapp/eal/meson.build | 2 +- meson.build | 4 +++- meson_options.txt | 1 + 7 files changed, 10 insertions(+), 6 deletions(-)
Signature · 1 line
2.11.0
PATCH 1/3 build: rename pkgconfig to libdpdk.pc
From: Luca Boccassi <[email protected]>
In Debian and Ubuntu we have been shipping a pkgconfig file for DPDK for more than a year now, and the filename is libdpdk.pc. A few downstream projects, like OVS and Collectd, have adopted the use of libdpdk.pc in their build systems as well.
In order to maintain backward compatibility, rename the file from DPDK.pc to libdpdk.pc.
--- meson.build | 1 + 1 file changed, 1 insertion(+)
meson.build +1 -0
@@ -81,6 +81,7 @@ endif pkg = import('pkgconfig') pkg.generate(name: meson.project_name(), + filebase: 'lib' + meson.project_name().to_lower(), version: meson.project_version(), libraries: dpdk_libraries, description: 'The Data Plane Development Kit (DPDK)',
Signature · 1 line
2.11.0
Re: [PATCH 1/3] build: rename pkgconfig to libdpdk.pc
Quoted 11 lines · On Fri, Sep 15, 2017 at 06:36:10PM +0100, [email protected] wrote:
From: Luca Boccassi <[email protected]>
In Debian and Ubuntu we have been shipping a pkgconfig file for DPDK for more than a year now, and the filename is libdpdk.pc. A few downstream projects, like OVS and Collectd, have adopted the use of libdpdk.pc in their build systems as well.
In order to maintain backward compatibility, rename the file from DPDK.pc to libdpdk.pc.Signed-off-by Luca Boccassi <[email protected]>---
I find the 'lib' bit strange, but if that is what is already out there, then we should keep it for compatibility.
In future, we might create two pkgconfig files to transition over to a new name, but to start with lets use what is being looked for by our dependencies.
Re: [PATCH 1/3] build: rename pkgconfig to libdpdk.pc
Quoted 12 lines · Bruce Richardson
Quoted 10 lines · On Fri, Sep 15, 2017 at 06:36:10PM +0100, [email protected] wrote:
From: Luca Boccassi <[email protected]>
In Debian and Ubuntu we have been shipping a pkgconfig file for DPDK
for more than a year now, and the filename is libdpdk.pc. A few downstream projects, like OVS and Collectd, have adopted the use of libdpdk.pc in their build systems as well.
In order to maintain backward compatibility, rename the file from DPDK.pc to libdpdk.pc.
Quoted 6 lines
Quoted 2 lines
Signed-off-by Luca Boccassi <[email protected]>---
I find the 'lib' bit strange, but if that is what is already out there,
then we should keep it for compatibility.
Not sure where the original name came from, it's been like that for a few years - it might have been my fault :-)
In Debian/Ubuntu libraries development headers, unversioned shared object symlinks and static archives always ship in packages named libfoo[api-ver]-dev. This is strictly enforced by policy. We have libdpdk-dev for example.
Then, usually, pkg-config files follow the same naming convention, so that if you want to build against libfoo-dev you use pkg-config libfoo. This makes it nice and predictable.
But IIRC it's not enforced, and not universally followed.
Quoted 6 lines
In future, we might create two pkgconfig files to transition over to a
new name, but to start with lets use what is being looked for by our dependencies.Acked-by Bruce Richardson <[email protected]>
Even just a symlink should work fine, at least it does with the pkg- config I have on Debian. Should not cause issues on any implementation.
Signature · 2 lines
Kind regards, Luca Boccassi
PATCH 2/3 build: add optional arch-specific headers install path
In reply to [email protected]From: Luca Boccassi <[email protected]>
A subset of the dpdk headers are arch-dependent, but have common names and thus cause a clash in a multiarch installation.
For example, rte_config.h is different for each target.
Add a "include_subdir_arch" option to allow a user to specify a subdirectory for arch independent headers to fix multiarch support.
--- config/meson.build | 2 +- lib/librte_eal/common/include/arch/x86/meson.build | 3 ++- meson.build | 3 ++- meson_options.txt | 1 + 4 files changed, 6 insertions(+), 3 deletions(-)
config/meson.build +1 -1
@@ -69,4 +69,4 @@ dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes')) dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet')) dpdk_conf.set('RTE_EAL_ALLOW_INV_SOCKET_ID', get_option('allow_invalid_socket_id')) -install_headers('rte_config.h') +install_headers('rte_config.h', subdir: get_option('include_subdir_arch'))
lib/librte_eal/common/include/arch/x86/meson.build +2 -1
@@ -45,4 +45,5 @@ install_headers( 'rte_rtm.h', 'rte_rwlock.h', 'rte_spinlock.h', - 'rte_vect.h') + 'rte_vect.h', + subdir: get_option('include_subdir_arch'))
meson.build +2 -1
@@ -70,7 +70,7 @@ subdir('app') build_cfg = 'rte_build_config.h' configure_file(output: build_cfg, configuration: dpdk_conf, - install_dir: get_option('includedir')) + install_dir: get_option('includedir') + '/' + get_option('include_subdir_arch')) # for static builds, include the drivers as libs, and also any # other dependent libs that DPDK needs to link against
@@ -85,5 +85,6 @@ pkg.generate(name: meson.project_name(), version: meson.project_version(), libraries: dpdk_libraries, description: 'The Data Plane Development Kit (DPDK)', + subdirs: [get_option('include_subdir_arch'), '.'], extra_cflags: '-include "rte_config.h"' )
meson_options.txt +1 -0
@@ -7,3 +7,4 @@ option('allow_invalid_socket_id', type: 'boolean', value: false, option('enable_kmods', type: 'boolean', value: true, description: 'build kernel modules') option('kernel_dir', type: 'string', value: '', description: 'path to the kernel for building kernel modules') option('per_library_versions', type: 'boolean', value: true, description: 'true: each lib gets its own version number, false: DPDK version used for each lib') +option('include_subdir_arch', type: 'string', value: '', description: 'subdirectory where to install arch-dependent headers')
Signature · 1 line
2.11.0
Re: [PATCH 2/3] build: add optional arch-specific headers install path
Quoted 43 lines · On Fri, Sep 15, 2017 at 06:36:11PM +0100, [email protected] wrote:
From: Luca Boccassi <[email protected]>
A subset of the dpdk headers are arch-dependent, but have common names and thus cause a clash in a multiarch installation.
For example,rte_config.his different for each target.Add a "
include_subdir_arch" option to allow a user to specify a subdirectory for arch independent headers to fix multiarch support.Signed-off-by Luca Boccassi <[email protected]>--- config/meson.build | 2 +- lib/librte_eal/common/include/arch/x86/meson.build | 3 ++- meson.build | 3 ++- meson_options.txt | 1 + 4 files changed, 6 insertions(+), 3 deletions(-)config/meson.build +1
-1@@ -69,4 +69,4 @@ dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes')) dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet')) dpdk_conf.set('RTE_EAL_ALLOW_INV_SOCKET_ID', get_option('allow_invalid_socket_id')) -install_headers('rte_config.h') +install_headers('rte_config.h', subdir: get_option('include_subdir_arch'))lib/librte_eal/common/include/arch/x86/meson.build +2
-1@@ -45,4 +45,5 @@ install_headers( 'rte_rtm.h', 'rte_rwlock.h', 'rte_spinlock.h', - 'rte_vect.h') + 'rte_vect.h', + subdir: get_option('include_subdir_arch'))meson.build +0
-0
meson.build subdir('app') · line 73
Quoted 5 lines
meson.build +1
-1@@ -70,7 +70,7 @@ subdir('app') build_cfg = 'rte_build_config.h' configure_file(output: build_cfg, configuration: dpdk_conf, - install_dir: get_option('includedir')) + install_dir: get_option('includedir') + '/' + get_option('include_subdir_arch'))
Minor nit: use "join_paths()" function. Will fix on apply.
PATCH 3/3 build: don't hard-code generic/exec-env install path
In reply to [email protected]From: Luca Boccassi <[email protected]>
Instead of hard-coding the install path of generic and exec-env headers use the includedir option, so that it can be correctly overridden.
--- lib/librte_eal/bsdapp/eal/meson.build | 2 +- lib/librte_eal/common/include/meson.build | 2 +- lib/librte_eal/linuxapp/eal/meson.build | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
lib/librte_eal/bsdapp/eal/meson.build +1 -1
@@ -30,7 +30,7 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. eal_inc += include_directories('include') -install_subdir('include/exec-env', install_dir: 'include') +install_subdir('include/exec-env', install_dir: get_option('includedir')) sources = ['eal_alarm.c', 'eal_debug.c',
lib/librte_eal/common/include/meson.build +1 -1
@@ -66,6 +66,6 @@ common_headers = [ 'rte_version.h'] install_headers(common_headers) -install_subdir('generic', install_dir : 'include') +install_subdir('generic', install_dir : get_option('includedir')) subdir('arch')
lib/librte_eal/linuxapp/eal/meson.build +1 -1
@@ -30,7 +30,7 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. eal_inc += include_directories('include') -install_subdir('include/exec-env', install_dir: 'include') +install_subdir('include/exec-env', install_dir: get_option('includedir')) sources = ['eal_alarm.c', 'eal_debug.c',
Signature · 1 line
2.11.0
Re: [PATCH 3/3] build: don't hard-code generic/exec-env install path
Quoted 7 lines · On Fri, Sep 15, 2017 at 06:36:12PM +0100, [email protected] wrote:
From: Luca Boccassi <[email protected]>
Instead of hard-coding the install path of generic and exec-env headers use the includedir option, so that it can be correctly overridden.
Signed-off-by Luca Boccassi <[email protected]>---
Quoted 18 lines · On Fri, Sep 15, 2017 at 06:36:09PM +0100, [email protected] wrote:
From: Luca Boccassi <[email protected]>
A couple of small fixes are needed in order to make the meson build compatible with Debian and Ubuntu, to avoid breaking backward compatibility for applications that depend on the packages.
Debian and Ubuntu have been shipping a pkg-config file for more than a year, but it is called libdpdk.pc rather than DPDK.pc. A few downstream projects, like OVS and Collectd, have started using it in with the former name.
To avoid breaking compatibility, rename it to libdpdk.pc.Furthermore, in order to avoid breaking multiarch installability, add an option to let users install arch-specific headers in another subdirectory of the arch-independent ones. The reason is that some of the arch specific ones have the same filename, so there is a clash. The new option,
include_subdir_arch, is disabled by default.
Quoted 8 lines
Finally a small fix to use the configure includedir rather than an hard-coded path for exec-env and generic headers.
Luca Boccassi (3):
build: rename pkgconfig to libdpdk.pc
build: add optional arch-specific headers install path
build: don't hard-code generic/exec-env install path
Series Applied to dpdk-next-build.
Thanks,
/Bruce