This is done in order to detect if user wants to build spdk RPMs
against DPDK RPMs that might have been installed on the system.
This boils down to the following:
- if --with-dpdk, with no argument, is detected don't build
separate RPM holding DPDK libs since user in this case is
most likely interested only in packaging the SPDK so it
can coexist with separate DPDK packaging workflow
- define install and build requirements for the SPDK RPMs
to depend on dpdk-devel RPM
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Change-Id: I4dd587009da282a114524c74d833fd35ebc5b985
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8349
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Karol Latecki <karol.latecki@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Alternative for the default of $HOME/rpmbuild.
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Change-Id: Id1feb7207926b518deb87045fc17bb3d1d4c374e
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8159
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
For now this is kept at its very basics. Dependencies are handled
via pgkdep, they are not explicitly defined by the .rpm itself.
Currently, up to four .rpm packages are being built:
spdk
spdk-devel
spdk-libs
spdk-dpdk-lib
Together they include all binaries|libs|header files + some setup
scripts which are commonly used throughout the repo. Installation
paths are hardcoded to:
/usr/local/{bin,lib{,/dpdk},include}:
- binaries
- libraries
- header files
/usr/libexec/spdk:
- scripts
/etc:
- configuration files
Signed-off-by: Michal Berger <michalx.berger@intel.com>
Change-Id: Ic5f067c4e7b8da3d697ee469bc9c794d5a0a035b
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6436
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
