08/01/2021 21:20, Honnappa Nagarahalli:

quoted

On Mon, Jan 04, 2021 at 05:46:20PM -0500, Andrew Boyer wrote:

quoted

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?

quoted

	../../dpdk/app/meson.build:48:3: ERROR: Tried to get unknown

variable "both_rte_ethdev".

quoted

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.

+1 for not supporting linking with both.

quoted

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.

quoted

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.

quoted

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.

me too
And I want to avoid linking static apps by default because they are huge.