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

["Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>]

> From: Gonzalez Monroy, Sergio
> Sent: Monday, January 12, 2015 5:22 PM
> To: Thomas Monjalon
> Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
> 
> 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.
> 
> > >  - For shared libraries, explicitly link against dependant
> > >    libraries (adding entries to DT_NEEDED).
> >
> > OK, good.
> >
> > >  - Update app linking flags against static/shared DPDK libs.
> > >
> > > Note that this patch turns up being quite big because of moving lib
> > > directories to a new subdirectory.
> > > I have ommited the actual diff from the patch doing the move of
> > > librte_eal as it is quite big (6MB). Probably a different approach
> > > is
> > preferred.
> >
> > Why do you think moving directories is needed?
> >
> Actually I am not sure is the best way to do this :) There is no need to move
> them, as the same result could be achieved without moving directories, but I
> thought that it would be easier for anyone to see which libraries are 'core'
> and which are not.
> 
> Not moving those directories would definitely simplify this patch series.
> 
> > Thanks
> > --
> > Thomas
> 
> Thanks,
> Sergio

Hi Thomas,

Any other comments/suggestions ? 
My main concern would be the patch needed to move librte_eal (around 6MB). 

Thoughts?

Thanks,
Sergio