Re: [dpdk-dev] [PATCH RFC 00/13] Update build system

[Neil Horman <nhorman@tuxdriver.com>]

On Mon, Jan 12, 2015 at 05:21:48PM +0000, Gonzalez Monroy, Sergio wrote:
> Hi Thomas,
> 
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Monday, January 12, 2015 4:52 PM
> > 
> > Hi Sergio,
> > 
> > 2015-01-12 16:33, Sergio Gonzalez Monroy:
> > > This patch series updates the DPDK build system.
> > 
> > Thanks for proposing such rework.
> > We need discussions on that topic. So I ask some questions below.
> > 
> > > Following are the goals it tries to accomplish:
> > >  - Create a library containing core DPDK libraries (librte_eal,
> > >    librte_malloc, librte_mempool, librte_mbuf and librte_ring).
> > >    The idea of core libraries is to group those libraries that are
> > >    always required for any DPDK application.
> > 
> > How is it better? Is it only to reduce dependencies lines?
> >
> In my opinion I think that there are a set of libraries that are always required
> and therefore should be grouped as a single one.
> Basically all apps and other DPDK libs would have dependencies to these core libraries.
> 
> Aside from that, I don't think there is any difference. Note that this affects shared libraries,
> with no difference for apps linked against static libs. 
> 
> > >  - Remove config option to build a combined library.
> > 
> > Why removing combined library? Is there people finding it helpful?
> > 
> I don't think it makes sense from a shared library point of view, maybe it does for static?
> For example, in the case of shared libraries I think we want to try to avoid the case where
> we have an app linked against librte_dpdk.so, but such library may contain different libraries
> depending on the options that were enabled when the lib was built.
> 
> The core libraries would be that set of libraries that are always required for an app, and its content
> would be fixed regardless of the option libraries (like acl, hash, distributor, etc.)
> We could add more libraries as core if we think it is a better solution, but the goal should be that
> librte_core.so contains the same libraries/API regardless of the system/arch.
> 

FWIW, I think Sergios approach is likely a good balance.  As he notes, mempool,
eal, malloc and mbuf are needed for any dpdk application, and have
interdepedencies, so it makes sense to link them as a single library.
Everything else is optional.  For static libraries, you can just add a few extra
lines to the linker, but for DSO's you might want the option of not linking
against a PMD, option to dynamically load it via the dlopen interface (using the
-d option).  Theres not much sense in adding those PMD DSO's to a single library
just to save a few lines in the makefile there.  This approach strikes a good
balance, combining items that will have to be linked together anyway, and
leaving everying else separate.
Neil