Hi,

I would like to use the Linux target for OpenWrt so I do not have to maintain a 
lot of extra code. For IP, Sockets and so on OpenWrt behaves like a normal 
Linux, just some demons OpenWrt uses are not common on other Linux 
distributions. For Bluetooth, iee802.15.4 and so on OpenWrt would use the 
standard Linux tools, but I thought is out of scope of IoTivity anyway.

My problem is that IoTivity currently only supports a small number of 
processors and also only a defined number of CFLAGS combinations. This causes 
problems when someone wants to build IoTivity for a new SoC with an 
architecture you haven't thought about before. This was my problem with the 
MIPS Big Endian CPUs. ;-)

Mainline OpenWrt currently supports about 50 different targets, some of them 
have own subtargtes which are getting their on compiler options to make use of 
all the features of this specific SoC or SoC family. 

I will probably carry these two patches in OpenWrt.

Hauke

-----Original Message-----
From: Zhang, Caiwen [mailto:[email protected]] 
Sent: Donnerstag, 11. Juni 2015 03:48
To: Mehrtens Hauke (LQKG BU AE PS SW); iotivity-dev at lists.iotivity.org
Subject: RE: IoTivity in OpenWrt with build variables from environment

The ideal way is to split OpenWrt from linux like Tizen. In the OpenWrt specific
Script(build_common/openwrt/SConscript) list the CFLAGS cases.

e.g.

help_vars = Variables()
help_vars.Add(EnumVariable('SoC', '<description of this option>', <default 
SoC>, [SoC lists]))
help_vars.Update(env)
Help(help_vars.GenerateHelpText(env))

Soc = env.get('SoC')

If soc == 'xxx':
        #flags ....
Elif soc == '...':
        #flags ....

...

A compromise solution is to move the environment updating into the OpenWrt 
specific script (build_common/openwrt/SConscript) to avoid impact other 
platforms. But I am not sure this solution is acceptable for other guys.

Regards,
Caiwen

> -----Original Message-----
> From: Hauke.Mehrtens at lantiq.com [mailto:Hauke.Mehrtens at lantiq.com]
> Sent: Wednesday, June 10, 2015 4:21 PM
> To: Zhang, Caiwen; iotivity-dev at lists.iotivity.org
> Subject: RE: IoTivity in OpenWrt with build variables from environment
> 
> Hi,
> 
> OpenWrt is similar to OpenEmbedded and Tizen. It is a Linux 
> distribution for home routers and uses cross compiling.
> Using TC_PREFIX=mips-openwrt-linux-uclibc- and  TC_PATH=<the toolchain 
> path> also works, but it still does not provide the CFLAGS and so on 
> to the build system. OpenWrt currently supports about 30 different 
> CFLAGS combinations [0] for the different SoCs its supports [1] adding 
> all that to the IoTivity build system will not scale.
> Normally you build the complete OpenWrt distribution at once and 
> IoTivity would only be one package, OpenWrt also takes care of 
> creating the correct toolchain and providing all packages with the correct 
> compile flags.
> Providing the flags through the environment is more or less the common 
> way many Linux software packages use.
> 
> If it is too much trouble to integrate these patches into IoToivity we 
> can also ship them with OpenWrt, like Tizen, OpenWrt is capable to 
> ship patches and apply them automatically.
> 
> [0]: https://dev.openwrt.org/browser/trunk/include/target.mk
> [1]: https://dev.openwrt.org/wiki/platforms
> 
> Hauke
> 
> -----Original Message-----
> From: Zhang, Caiwen [mailto:caiwen.zhang at intel.com]
> Sent: Mittwoch, 10. Juni 2015 04:38
> To: Mehrtens Hauke (LQKG BU AE PS SW); iotivity-dev at lists.iotivity.org
> Subject: RE: IoTivity in OpenWrt with build variables from environment
> 
> It seems what you'd like is to add custom compiling configuration. The 
> adding environment way works in proper situation but it may introduce 
> trouble when build for other platform and archs. The config in 
> environment is correct for OpenWrt, but it may not be suitable for 
> other platforms and archs.
> 
> I don't familiar with OpenWrt. Can it be handled as cross-compiling? 
> If yes, you can have a try With below options:
>  TC_PREFIX=mips-openwrt-linux-uclibc-   TC_PATH=<the toolchain path>
> 
> If not, it should be better to put the custom config in a script and 
> load it from some proper place When build for Openwrt.
> 
> Regards,
> Caiwen
> 
> > -----Original Message-----
> > From: iotivity-dev-bounces at lists.iotivity.org
> > [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of 
> > Hauke.Mehrtens at lantiq.com
> > Sent: Tuesday, June 09, 2015 4:07 PM
> > To: iotivity-dev at lists.iotivity.org
> > Subject: [dev] IoTivity in OpenWrt with build variables from 
> > environment
> >
> > We want to use IoTivity on MIPS CPUs running in big endian mode with 
> > OpenWrt as the Linux distribution. It would be nice to make it 
> > possible to add IoTivity to mainline OpenWrt, it supports many CPU
> architectures.
> > Currently the scons build systems sets all the parameters for gcc 
> > and so on by itself base on the architecture specified, this is the 
> > way one should go with scons as far as I know. I think this does not 
> > scale, when you want to support many different CPU architectures 
> > with different gcc optio,ns it will get a mess. OpenWrt calls the 
> > scons build system with all the necessary options for this specific 
> > target in it
> environment variables. It looks like this:
> >
> > CC="mips-openwrt-linux-uclibc-gcc" \ 
> > CXX="mips-openwrt-linux-uclibc-g++" \ 
> > AR="mips-openwrt-linux-uclibc-ar" \ 
> > RANLIB="mips-openwrt-linux-uclibc-ranlib" \ CFLAGS="-Os -pipe
> > -mips32r2 -mtune=1004kc -fno-caller-saves -fhonour-copts 
> > -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float "\ 
> > CXXFLAGS="-Os -pipe -mips32r2 -mtune=1004kc -fno-caller-saves 
> > -fhonour-copts -fhonour-copts -Wno-error=unused-but-set-variable
> > -msoft-float " \
> >
> CPPFLAGS="-I/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/st
> >
> aging_dir/target-mips_r2_uClibc-0.9.33.2_grx350_gw_he_vdsl_lte/usr/in
> > clude
> >
> -I/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/staging_dir/tar
> > get-mips_r2_uClibc-0.9.33.2_grx350_gw_he_vdsl_lte/include
> >
> -I/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/staging_dir/to
> > olchain-mips_r2_gcc-4.8-linaro_uClibc-0.9.33.2/usr/include
> >
> -I/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/staging_dir/to
> > olchain-mips_r2_gcc-4.8-linaro_uClibc-0.9.33.2/include " \
> >
> LDFLAGS="-L/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/sta
> >
> ging_dir/target-mips_r2_uClibc-0.9.33.2_grx350_gw_he_vdsl_lte/usr/lib
> >
> -L/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/staging_dir/ta
> > rget-mips_r2_uClibc-0.9.33.2_grx350_gw_he_vdsl_lte/lib
> >
> -L/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/staging_dir/to
> > olchain-mips_r2_gcc-4.8-linaro_uClibc-0.9.33.2/usr/lib
> >
> -L/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/staging_dir/to
> > olchain-mips_r2_gcc-4.8-linaro_uClibc-0.9.33.2/lib " \
> >
> DESTDIR="/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/build
> >
> _dir/target-mips_r2_uClibc-0.9.33.2_grx350_gw_he_vdsl_lte/iotivity-0.9.
> > 1-RC1/ipkg-install" \ scons \ TARGET_OS=linux \
> TARGET_TRANSPORT=ALL \
> > TARGET_ARCH=mips \
> >
> STAGING_DIR=/disk/fs1/tmp2/mehrtens/UGW/UGW-new/openwrt/core/s
> > taging_dir/target-mips_r2_uClibc-0.9.33.2_grx350_gw_he_vdsl_lte \ 
> > VERBOSE=true \ LOGGING=yes
> >
> >
> > I created the attached patch 004-use-env.patch to use these 
> > environment variables instead of the variables hard coded in the 
> > IoTivity build files. In addition I had to allow the mips 
> > architecture with patch 003-add-mips.patch.
> >
> > Is this the right approach or how should I handle it? I do not think 
> > adding every option to the IoTivity build files will work, for 
> > example see -mtune this will be different for many SoCs. I also 
> > would like to get such a patch into upstream IoTivity so I do not 
> > have to take care of it manually. The attached Makefile is the 
> > OpenWrt Makefile with all the IoTivity specific options.
> >
> >
> > Hauke Mehrtens
> > Lantiq Beteiligungs-GmbH & Co.KG
> >
> > office:      Lilienthalstra?e 15, 85579 Neubiberg Germany
> > phone:    +49 (89) 89899 - 7179
> > e-mail:     hauke.mehrtens at lantiq.com
> 


Reply via email to