I've been attempting to perform a build of the SPDK that relies on a different env_dpdk implementation, but am running into trouble. The documentation's porting guide is a little sparse, but between that, a fragment from an email to the list:
point SPDK at a different implementation of include/spdk/env.h through the
and some experimentation, I've not deduced exactly how this is supposed to work.
I grabbed a copy of a default built libspdk_env_dpdk.a and placed it in my ~/src/my_own_env_dpdk directory, and ran configure setting '--with-env=~/src/my_own_env_dpdk/libspdk_env_dpdk.a', but a build quickly fails because SPDK_ROOT_DIR/mk/spdk_common.mk attempts to do an include of an env.mk therein:
SPDK_ROOT_DIR/mk/spdk_common.mk:170: ~/src/my_own_env_dpdk/libspdk_env_dpdk.a/env.mk: Not a directory
The porting guide and the behavior of the build would indicate that CONFIG_ENV needs to be a directory.
Am I missing something fundamental in my configuration setup? Or, perhaps, did this work a while back, but over time changes to the build process broke it? I tried fudging with it further by doing things like copying the original SPDK_ROOT_DIR/lib/env_dpdk/env.mk to my own directory (and re-running the configure setting '--with-env' to just the directory, ~/src/my_own_env_dpdk), and kicking off the build. That allows the build to run a lot further, but ultimately it fails later and I would suspect we wouldn't be imposing a requirement that one's own env implementation necessarily has to have an 'env.mk'. Also, there seem to be other elements in the build process later on that don't consider CONFIG_ENV when you get to the linking stages.