From: Thomas Monjalon <thomas@monjalon.net>
To: Olivier MATZ <olivier.matz@6wind.com>,
"Eads, Gage" <gage.eads@intel.com>
Cc: dev@dpdk.org, "'Jacob,
Jerin'" <Jerin.JacobKollanukkaran@cavium.com>,
"santosh.shukla@caviumnetworks.com"
<santosh.shukla@caviumnetworks.com>,
bruce.richardson@intel.com
Subject: Re: [dpdk-dev] Inter-PMD dependencies when building shared libraries
Date: Thu, 05 Oct 2017 14:32:06 +0200 [thread overview]
Message-ID: <2164137.oDFHlng5hp@xps> (raw)
In-Reply-To: <20171005121254.r3h43hxs423dxr4k@glumotte.dev.6wind.com>
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.
next prev parent reply other threads:[~2017-10-05 12:32 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 [this message]
2017-10-05 12:50 ` Bruce Richardson
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=2164137.oDFHlng5hp@xps \
--to=thomas@monjalon.net \
--cc=Jerin.JacobKollanukkaran@cavium.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=olivier.matz@6wind.com \
--cc=santosh.shukla@caviumnetworks.com \
/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).