From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 32373C486 for ; Thu, 23 Jun 2016 10:54:01 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 23 Jun 2016 01:54:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,515,1459839600"; d="scan'208";a="993501197" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.161]) by fmsmga001.fm.intel.com with SMTP; 23 Jun 2016 01:53:58 -0700 Received: by (sSMTP sendmail emulation); Thu, 23 Jun 2016 09:53:57 +0025 Date: Thu, 23 Jun 2016 09:53:57 +0100 From: Bruce Richardson To: Olivier Matz Cc: Thomas Monjalon , Panu Matilainen , dev@dpdk.org, cristian.dumitrescu@intel.com, zhuangwj@gmail.com Message-ID: <20160623085356.GB10864@bricha3-MOBL3> References: <191edb8105649612fab5f0e691f587715b78e664.1466595242.git.pmatilai@redhat.com> <293319946.9flpxUKHBY@xps13> <576A7D20.4030801@6wind.com> <1598312.eZ7tuG1m5F@xps13> <576AAF95.7040906@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <576AAF95.7040906@6wind.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] port: fix build when KNI support is not enabled X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 08:54:01 -0000 On Wed, Jun 22, 2016 at 05:32:37PM +0200, Olivier Matz wrote: > On 06/22/2016 02:20 PM, Thomas Monjalon wrote: > > 2016-06-22 13:57, Olivier Matz: > >> Hi Thomas, > >> > >> On 06/22/2016 01:49 PM, Thomas Monjalon wrote: > >>> 2016-06-22 14:34, Panu Matilainen: > >>>> --- a/lib/librte_port/Makefile > >>>> +++ b/lib/librte_port/Makefile > >>>> @@ -82,6 +82,8 @@ DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_mempool > >>>> DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ether > >>>> DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ip_frag > >>>> DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_sched > >>>> +ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) > >>>> DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_kni > >>>> +endif > >>> > >>> I do not remember why $(CONFIG_RTE_LIBRTE_PORT) is needed in its Makefile. > >>> I think we can do > >>> DEPDIRS-$(CONFIG_RTE_LIBRTE_KNI) += lib/librte_kni > >>> and set DEPDIRS-y everywhere else. > >>> > >> > >> It's probably not much used, but the build framework allows to do > >> the following to build only one directory: > >> > >> make lib/librte_port_sub > >> > >> This directly jumps to the librte_port Makefile, bypassing parent > >> directories. I think that's why the config check is duplicated in the > >> Makefile. > > > > If we want to specifically build this directory, why preventing us to do > > so with CONFIG_RTE_LIBRTE_PORT? > > If we call foo_sub with CONFIG_FOO=n, it will generate a library and > install headers in the build directory, however the config is unset. > Some propositions if we want to replace > DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) by DEPDIRS-y: > > 1/ say that "make foo_sub" should be used with care, only if CONFIG_FOO > is set (else it is not supported) -> nothing to do > 2/ fix the make %_sub feature to browse parent directories, checking > the SUBDIRS-${CONFIG_FOO} > 3/ remove the make %_sub feature, maybe nobody cares... > > I think 1/ is acceptable. +1 Especially given the fact I wasn't even aware that you could do that (building just one subdir). Do we have a usecase where people might want to build just one DPDK subdirectory? /Bruce