[dpdk-dev] [PATCH v14 00/12] Arm build options rework

Bruce Richardson bruce.richardson at intel.com
Fri Jan 8 18:36:45 CET 2021


On Mon, Jan 04, 2021 at 05:46:20PM -0500, Andrew Boyer wrote:
> 
> 1)  Bruce - when the “-Ddefault_library=both” flag is passed in, the build fails with this error. It’s been broken for a long time; maybe this option isn’t supported and should be blocked earlier?
> 
> 	../../dpdk/app/meson.build:48:3: ERROR: Tried to get unknown variable "both_rte_ethdev".
> 
Revisiting this point, since there are a number of possible approaches we
can take here, and I'd like feedback on them before we do anything. Of
these approaches, 2 are simple, and 1 is more complicated.

1. We can just detect this as an invalid/unsupported setting and error out
earlier with a suitable errors message
2. Since we already support in all cases building "both" libraries, we can
just convert "both" to be the same as "shared" for app linking (since app
linking is all the value is actually used for by us)
3. We can change how we do the builds to actually repect the value as
intended - only build static or shared libs as requested and only build
both when value "both" is passed.

Of these, #3 is obviously the most work, but may make the most sense to
users. However, it does have the following open issues - which are all linked:
1. What way do we make the default linkage in the case of "both" being
selected?
2. What do we make the default for builds?
3. Is there ever a case where someone needs both libraries build but
non-default linkage?

The initial answers I thought for these would be that the default for
"both" builds should be "shared", and that "both" should be the default.
However, that then is a behaviour change for DPDK since we don't get
static binaries by default. The solution to that is that we change the
default to "static", but then we revert to the situation we used to have
with the make build where we regularly got patches upstreamed which failed
to build with shared libs because the map file update was missing and the
submitter never tested shared builds. The third alternative there is that
we default to "both" but have "static" binaries when that is selected. That
option runs against question #3 where I suspect there will be cases (e.g.
packaging) where one does want both library sets generated but shared
binaries.

Therefore, is keeping things largely as they are and taking the simpler
options #1 or #2 better? Do we want to look into #3 but with further
additions such as a "default_app_linkage" DPDK option, or linking all apps
twice when "both" is specified as "default_library"?

Feedback welcome please.

/Bruce

PS: For background, when the DPDK transition to meson started, there
wasn't a "both" option which is why this is not the best supported. :-)


More information about the dev mailing list