08/01/2021 21:20, Honnappa Nagarahalli: > > 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.
+1 for not supporting linking with both. > > 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. me too And I want to avoid linking static apps by default because they are huge.
