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:

[...]
You can
point SPDK at a different implementation of include/spdk/env.h through the
configuration script:

./configure --with-env=/path/to/your/lib.a

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.


Thx,
Lance