[dpdk-dev] [PATCH] mk: generate internal library dependencies from DEPDIRS-y automatically

[Bruce Richardson]

On Tue, Jun 07, 2016 at 04:19:47PM +0200, Thomas Monjalon wrote:
> 2016-06-07 15:07, Bruce Richardson:
> > On Tue, Jun 07, 2016 at 03:00:45PM +0200, Thomas Monjalon wrote:
> > > 2016-06-07 14:36, Christian Ehrhardt:
> > > > But I still struggle to see how to fix the circular dependency between
> > > > librte_eal and librte_mempool.
> > > 
> > > Why is there a circular dependency?
> > > Only because of logs using mempool?
> > > 
> > > > Maybe now is a time to look at this part of the original threads again to
> > > > eventually get apps less overlinked?
> > > > => http://www.dpdk.org/ml/archives/dev/2016-May/039441.html
> > > > My naive suggestions in generalized form can be found there (no answer yet):
> > > > =>
> > > > http://stackoverflow.com/questions/37351699/how-to-create-both-so-files-for-two-circular-depending-libraries
> > > 
> > > I would prefer removing the circular dependency.
> > > Maybe we can rewrite the code to not use mempool or move it outside of EAL.
> > 
> > Or else we can take the attitude that the mempools and the rings are just a core
> > part of DPDK and move them and the EAL into a dpdk_core library at link time.
> > Having the code separate in the git tree is good, but I'm not sure having
> > the resulting object files being in separate .a/.so files is particularly useful.
> > I can't see someone wanting to use one without the other.
> 
> EAL could be used as an abstraction layer on top of systems and platforms.
> And I think keeping things separated and layered help to maintain a design
> easy to understand.

All that applies to the code, not so much to the resulting libraries generated.
I don't see how having a separate eal.so and mempool.so particularly helps in
any way, except to require more flags for linking.

/Bruce