Re: [meta-networking][PATCH 4/4] freeradius: add PACKAGECONFIGs

[Changqing Li <changqing.li@windriver.com>]

On 2/28/19 12:35 AM, Tom Rini wrote:
> On Wed, Feb 27, 2019 at 04:41:50PM +0800, changqing.li@windriver.com wrote:
>
>> From: Changqing Li <changqing.li@windriver.com>
>>
>> add 3 PACKAGECONFIG
>>
>> Signed-off-by: Changqing Li <changqing.li@windriver.com>
>> ---
>>   meta-networking/recipes-connectivity/freeradius/freeradius_3.0.17.bb | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/meta-networking/recipes-connectivity/freeradius/freeradius_3.0.17.bb b/meta-networking/recipes-connectivity/freeradius/freeradius_3.0.17.bb
>> index c17d56d..cee3b47 100644
>> --- a/meta-networking/recipes-connectivity/freeradius/freeradius_3.0.17.bb
>> +++ b/meta-networking/recipes-connectivity/freeradius/freeradius_3.0.17.bb
>> @@ -83,6 +83,9 @@ PACKAGECONFIG[perl] = "--with-perl=${STAGING_BINDIR_NATIVE}/perl-native/perl --w
>>   PACKAGECONFIG[python] = "--with-rlm_python --with-rlm-python-bin=${STAGING_BINDIR_NATIVE}/python-native/python --with-rlm-python-include-dir=${STAGING_INCDIR}/${PYTHON_DIR},--without-rlm_python,python-native python"
>>   PACKAGECONFIG[rest] = "--with-rlm_rest,--without-rlm_rest,curl json-c"
>>   PACKAGECONFIG[ruby] = "--with-rlm_ruby,--without-rlm_ruby,ruby"
>> +PACKAGECONFIG[no-ssl] = "--without-openssl,--with-openssl"
> This is commonly done with 'openssl' as the PACKAGECONFIG flag.
>
>> +PACKAGECONFIG[no-rlm-eap-fast] = "--without-rlm_eap_fast,--with-rlm_eap_fast"
>> +PACKAGECONFIG[no-rlm-eap-pwd] = "--without-rlm_eap_pwd,--with-rlm_eap_pwd"
> We also don't have any other examples of "no-xxx".  What is the behavior
> we have here today?  If "enabled" we should put them in the default
> PACKAGECONFIG instead, imho.
>
Hi, Khem

My original idea is default option is enable,  add 
PACKAGECONFIG[disable-xxx] is for

someone who want to disable it by append PACKAGECONFIG.  but if we have the

traditional way  like tom and Adrian said,  I am ok with that way.


I noticed that this patch is now on master-next,  so I will send a 
!fixup  of these patches based on master-next

branch in case we need to keep the traditional way.   Sorry for the 
inconvenient.


-- 
BRs

Sandy(Li Changqing)