[dpdk-dev] Inter-PMD dependencies when building shared libraries

Thomas Monjalon thomas at monjalon.net
Thu Oct 5 14:32:06 CEST 2017


05/10/2017 14:12, Olivier MATZ:
> On Mon, Oct 02, 2017 at 08:48:29PM +0000, Eads, Gage wrote:
> > I believe I've spotted an issue in the way inter-PMD dependencies are handled when building shared libraries. The depdirs_rule in mk/rte.subdir.mk relies on DEPDIRS-xyz containing the names of subdirectories that xyz depends on. In mk/rte.lib.mk, these DEPDIRS are converted into LDLIBS. This works when the subdirectory names match the library names (i.e. any of the libraries under lib/). However when the dependency is on a PMD, the subdirectory and library names don't match.
[...]
> To solve this, we can either:
> 
> 1- do additional fixes of the "dir name -> lib name" conversion in
>    lib.mk for all this list above, as we are doing for eal or
>    ethdev. This looks feasible, but quite ugly.
> 
> 2- rename all directories to match the libname (ex: drivers/net/null
>    becomes drivers/net/librte_pmd_null). Looks to be a bad idea ;)
> 
> 3- stop to generate the list of libraries from depdirs: DEPDIRS is
>    kept for directory dependency at build, and the list of libraries
>    is advertised in LDLIBS variable, in each Makefile.
> 
> My vote would go for option 3.

We could have several libraries in the same directory.
So I vote for option 4:

4- Replace directory dependencies with library dependencies in makefiles.
   And convert libs to dirs with an autogenerated table.

Note: that's why I don't like recursive makefiles like we have
in the DPDK build system. It forces us to deal with directories
instead of just declaring dependencies on real file targets.


More information about the dev mailing list