From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Olivier MATZ <olivier.matz@6wind.com>,
"Eads, Gage" <gage.eads@intel.com>,
dev@dpdk.org, "'Jacob,
Jerin'" <Jerin.JacobKollanukkaran@cavium.com>,
"santosh.shukla@caviumnetworks.com"
<santosh.shukla@caviumnetworks.com>
Subject: Re: [dpdk-dev] Inter-PMD dependencies when building shared libraries
Date: Thu, 5 Oct 2017 13:50:17 +0100 [thread overview]
Message-ID: <20171005125017.GA12160@bricha3-MOBL3.ger.corp.intel.com> (raw)
In-Reply-To: <2164137.oDFHlng5hp@xps>
On Thu, Oct 05, 2017 at 02:32:06PM +0200, Thomas Monjalon wrote:
> 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.
IF we have time to implement your solution 4, then sure. However, if we
want this fixed for 17.11, I think 3 sounds reasonable.
For option 2, renaming directories to standardise things a bit would be
nice, as it would simplify things a bit for the new meson build system -
I could remove the "name" override value for each lib - but I don't
think it would help much in this case without making things extremely
ugly with using full library names as you suggest.
So I think option 3 or 4 is what is needed.
This should not be a problem using meson build, as libs and drivers are
already tracked using dependency objects across build directories.
However, we do need to ensure that our dependencies are always in the
right order, we can't have a NIC pmd driver depending on a mempool
driver, while another mempool driver depends on a different NIC driver.
We need to be able to scan the driver subdirs in a fixed order and have
all dependencies declared before they are needed.
/Bruce
next prev parent reply other threads:[~2017-10-05 12:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 20:48 Eads, Gage
2017-10-05 12:12 ` Olivier MATZ
2017-10-05 12:32 ` Thomas Monjalon
2017-10-05 12:50 ` Bruce Richardson [this message]
2017-10-12 16:04 ` [dpdk-dev] [PATCH 0/3] mk: fix LDLIBS Olivier Matz
2017-10-12 16:04 ` [dpdk-dev] [PATCH 1/3] crypto/dpaa2_sec: remove uneffective dependency Olivier Matz
2017-10-12 16:04 ` [dpdk-dev] [PATCH 2/3] mempool/octeontx: fix dependency Olivier Matz
2017-10-12 16:04 ` [dpdk-dev] [PATCH 3/3] mk: do not generate LDLIBS from directory dependencies Olivier Matz
2017-10-24 0:11 ` Thomas Monjalon
2017-10-23 14:39 ` [dpdk-dev] [PATCH 0/3] mk: fix LDLIBS Eads, Gage
2017-10-24 0:15 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171005125017.GA12160@bricha3-MOBL3.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=Jerin.JacobKollanukkaran@cavium.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=olivier.matz@6wind.com \
--cc=santosh.shukla@caviumnetworks.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).