From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 6F792B457
 for <dev@dpdk.org>; Wed, 22 Jun 2016 17:32:46 +0200 (CEST)
Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214]
 helo=[192.168.0.10])
 by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <olivier.matz@6wind.com>)
 id 1bFkBH-0002OA-Da; Wed, 22 Jun 2016 17:35:08 +0200
To: Thomas Monjalon <thomas.monjalon@6wind.com>
References: <191edb8105649612fab5f0e691f587715b78e664.1466595242.git.pmatilai@redhat.com>
 <293319946.9flpxUKHBY@xps13> <576A7D20.4030801@6wind.com>
 <1598312.eZ7tuG1m5F@xps13>
Cc: Panu Matilainen <pmatilai@redhat.com>, dev@dpdk.org,
 cristian.dumitrescu@intel.com, zhuangwj@gmail.com
From: Olivier Matz <olivier.matz@6wind.com>
Message-ID: <576AAF95.7040906@6wind.com>
Date: Wed, 22 Jun 2016 17:32:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Icedove/38.6.0
MIME-Version: 1.0
In-Reply-To: <1598312.eZ7tuG1m5F@xps13>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2016 15:32:46 -0000

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.