From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id D365737B1 for ; Thu, 5 Oct 2017 14:32:11 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4A64220AFF; Thu, 5 Oct 2017 08:32:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 05 Oct 2017 08:32:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=vptErYSbXMg7VqZ wABv9KkQSJzT1longs3tacgiGJQo=; b=POrAvUTKztl3M1i50kqbklRigVh99lG dVgwQXkYnozbk0rkwHrWiCZOm6FKU8JlfB1YGNOKx76LC7ZFonQkzWz8gtRC600r WGKgbuq87MxqSmhADV1xwIXv9svSM0mLzjCYyVfoYMLEVCXSuAXyjSmVoPuazFpe MFAJXtLVtzoA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=vptErYSbXMg7VqZwABv9KkQSJzT1longs3tacgiGJQo=; b=oLrh2jkK T2IGAf/fX1aVZX79Ac/zbX+Mr6f2nOzZPS/pjxpmjf1iYc1yN+VhPThX8uzcnlly tQLwNMAjTBx78ZI49VhKMUn03VsgltXvWg0bc6E/xcyfH0PPfbdqFJxok9oflCcZ V3lt2jZM9bVGMLTU3UlqWu8JpeJRtlDhV5jRbEKfq+ILoDsQP6vX9yu+4HPoo+G9 0WvgY1AOrAhuHQydShecjCeq0A+LZiwyphHyEIIdLGNfv0Wp5629SawNPW0DWhuY T3636CPojlD4bRD5a65pttutYwNlL1ld2XumrruJRPG23dt74g1tTqj73Z9zNSlV lbYhIK++kfBJxA== X-ME-Sender: X-Sasl-enc: o2N3cFE6Z1C0y1HrkG/o+uettosQFF5qQagBEE/oq9f4 1507206730 Received: from xps.localnet (unknown [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DCA1E7FA83; Thu, 5 Oct 2017 08:32:10 -0400 (EDT) From: Thomas Monjalon To: Olivier MATZ , "Eads, Gage" Cc: dev@dpdk.org, "'Jacob, Jerin'" , "santosh.shukla@caviumnetworks.com" , bruce.richardson@intel.com Date: Thu, 05 Oct 2017 14:32:06 +0200 Message-ID: <2164137.oDFHlng5hp@xps> In-Reply-To: <20171005121254.r3h43hxs423dxr4k@glumotte.dev.6wind.com> References: <9184057F7FC11744A2107296B6B8EB1E14005F70@FMSMSX108.amr.corp.intel.com> <20171005121254.r3h43hxs423dxr4k@glumotte.dev.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:32:12 -0000 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.