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

[Honnappa Nagarahalli]

<snip>

> 
> 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
I would prefer option 1 here (detect and error out). IMO, the option "both" does not seem to solve a compelling problem. I would prefer to avoid the additional code and complications. Mostly, everyone would do the development with either 'static' or 'shared' and test the other at the end when the development is completed.

> 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
I do not think option 2 solves the problem completely. i.e. if the user specifies 'both', app needs to be built for both static and shared libraries.

> 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.
I have been one among submitting the patches without testing for shared libraries. But, I am thinking that we have a good CI now that compiles for various combinations. I think that should be enough.

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"?
I would say stick with #1 as there is not a compelling problem to solve.

> 
> 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. :-)