From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 3BC549FE for ; Thu, 5 Oct 2017 14:50:21 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2017 05:50:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,481,1500966000"; d="scan'208";a="159186807" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.37]) by fmsmga005.fm.intel.com with SMTP; 05 Oct 2017 05:50:18 -0700 Received: by (sSMTP sendmail emulation); Thu, 05 Oct 2017 13:50:17 +0100 Date: Thu, 5 Oct 2017 13:50:17 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: Olivier MATZ , "Eads, Gage" , dev@dpdk.org, "'Jacob, Jerin'" , "santosh.shukla@caviumnetworks.com" Message-ID: <20171005125017.GA12160@bricha3-MOBL3.ger.corp.intel.com> References: <9184057F7FC11744A2107296B6B8EB1E14005F70@FMSMSX108.amr.corp.intel.com> <20171005121254.r3h43hxs423dxr4k@glumotte.dev.6wind.com> <2164137.oDFHlng5hp@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2164137.oDFHlng5hp@xps> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] Inter-PMD dependencies when building shared libraries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 12:50:22 -0000 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