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

[Changqing Li]

On 2/28/19 10:57 AM, Changqing Li wrote:
>
> On 2/28/19 12:35 AM, Tom Rini wrote:
>> On Wed, Feb 27, 2019 at 04:41:50PM +0800, changqing.li at windriver.com 
>> wrote:
>>
>>> From: Changqing Li <changqing.li at windriver.com>
>>>
>>> add 3 PACKAGECONFIG
>>>
>>> Signed-off-by: Changqing Li <changqing.li at 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.

I also need to  correct my commit message, so I will send a v2 today.

>
>
-- 
BRs

Sandy(Li Changqing)