On Jul 18, 2018, at 11:35 PM, Luse, Paul E <paul.e.luse@intel.com> wrote:

Hi Lance,
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!

With much thanks to Ben yesterday,


it's possible again now to build with an alternate environment.   Digging through the SPDK build makefiles and working with Ben has raised my awareness of some of the details regarding alternate environment configuration and building.   The first item that becomes immediately apparent is that building with an alternate environment is not quite as simple as merely specifying '--with-env=/path/to/alt_env_directory'.   As currently implemented, the build of the SPDK requires that /path/to/alt_env_directory contains a makefile and it must be named 'env.mk', and therein specifically-named variables must be defined.  More on this later.

Another especially notable take-away for me was the realization that the environment library -- I'll refer to the default env for example here, libspdk_env_dpdk.a -- consists only of the objects compiled from SPDK_ROOT_DIR/lib/env_dpdk.   With the ability to specify an alternate environment, semantically, I had mistakenly assumed that the env library would contain not only the SPDK implementation of the environment API, but also everything on which it depended; i.e. for the default environment, the DPDK objects.   But, that doesn't appear to be so.   Instead, when performing final linking of each SPDK executable, not only is the SPDK environment library specified, but so are the necessary DPDK libs on which it depends.   Variables pulled in from the SPDK's environment makefile, env.mk, are used to specify those DPDK libs along with additional, special linking flags.

We need to update the doc's Porting Guide to reflect these details, and I'd be happy to volunteer to work on that effort. However, before embarking on that task, I'd like to pose the question:   are there reasons why we couldn't or shouldn't produce the environment library to consist of both the SPDK env implementation layer and the objects on which it depends?  It would seem that would make final linking of executables a little easier and reduce the complexity/effort of someone wanting to develop and use an alternate environment.

Lance Hartmann

From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Lance Hartmann ORACLE
Sent: Wednesday, July 18, 2018 5:07 PM
To: spdk@lists.01.org
Subject: [SPDK] Howto build with an external env, i.e. alternate CONFIG_ENV
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.
SPDK mailing list