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