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.
