On Jul 18, 2018, at 11:35 PM, Luse, Paul E
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.
From: SPDK [mailto:email@example.com] On Behalf Of Lance
Sent: Wednesday, July 18, 2018 5:07 PM
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:
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:
~/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