[oe] [meta-networking][PATCH 4/4] freeradius: add PACKAGECONFIGs
Changqing Li
changqing.li at windriver.com
Thu Feb 28 02:57:38 UTC 2019
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.
--
BRs
Sandy(Li Changqing)
More information about the Openembedded-devel
mailing list