I’m not sure when the last time someone actually tried this was – a few key folks are out this week so if you don’t hear something here you might try back or see if anyone familiar with actually doing this is on IRC over the next few days… would be great to fix anything here that’s busted though and really, really great to update the porting guide!
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.