On 6/7/16, 9:19 AM, "dev on behalf of Thomas Monjalon" <dev-bounces at dpdk.org on behalf of thomas.monjalon at 6wind.com> 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. One of the other areas I see as an issue when building DPDK is the headers are only linked into place as the makefile is executed causing a dependency on build order. If you have a circular dependency on building libs or core code we have to link directly. Would this problem be helped if we had a two pass type build system, one to link the headers and then build the libraries? >
