Hi Thiago, I have a question that is different from the topic in this mail thread. It seems that Intel will support OpenWRT, OSX platform in IoTivity0.9.2 or later. Right?
Regards June June Yong Young OIC Open Sourece WG Project Planning & Requirement TG Chair IoTivity Release Function Lead Samsung Electronics Co.,Ltd. Software R&D Center, IoT Solution Lab. | Web & Convergence Team Principal Engineer T: +82-31-301-6107, M: +82-10-9530-6107 E-mail :juney at samsung.com -----Original Message----- From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of Jon A. Cruz Sent: Friday, June 19, 2015 12:56 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] IoTivity in OpenWrt with build variables from environment On 06/18/2015 08:38 AM, Thiago Macieira wrote: > On Thursday 18 June 2015 13:40:58 Hauke.Mehrtens at lantiq.com wrote: >> What is the opinion on adding some option where IoTivity does not do >> its architecture specific changes to CPPFLAGS and similar flags? In >> this mode someone from the outside has to provide these information. > > My opinion is that this should be the default and only mode. Any build > options such as disabling of the C++ API or the primitive services > need to be options of their own, as opposed to implied from the architecture. > > But this is just my opinion, I can't make the decision. First, I agree with Thiago in aspects where we avoid explicit command-line switches to the build to change behavior. The build should *always* be considering the current environment when it is run. (however, we should watch out for hiding things in the environment and not noticing them) If we look at autotools for some examples, environment variables always come in. Defaults can be explicitly set in the scripts to be used when the user does not have them set in the invoking environment. You get three variables per 'project/target': CPPFLAGS AM_CPPFLAGS foo_CPPFLAGS CPPFLAGS would be the primarily user-oriented ones and scripts should avoid setting that. AM_CPPFLAGS is used for the project-wide flags foo_CPPFLAGS is used for the sub-project/executable specific flags for the 'foo' program. The most specific ones (e.g. foo_CPPFLAGS) would normally chain in the others and just add to it. So CPPFLAGS can be changed by the user per build invocation. AM_CPPFLAGS can possibly be changed by the user at configuration time or at build invocation time. Normally that would suffice, although a user could also override foo_CPPFLAGS if needed. Additionally we should consider things like CFLAGS, CPPFLAGS, and CXXFLAGS. For specifying compilers, setting CC and CXX are common. Those should cover Hauke's case of the user specifying their own compiler name. Setting CFLAGS and CXXFLAGS. So one might hypothetically do something like CC=/home/person/custom_xcc/cc CFLAGS='-v -O9 --magic' scons (I believe the reason we need to explicitly consider all this is that SCons is a toolkit to allow us to make a build system, as opposed to pre-canned build systems like autotools or cmake. Thus we explicitly have to code the behaviors we choose) -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
