Hi, > ________________________________________ > From: iotivity-dev-bounces at lists.iotivity.org [iotivity-dev-bounces at > lists.iotivity.org] on behalf of Jon A. Cruz [jonc at osg.samsung.com] > Sent: Friday, June 19, 2015 5:56 AM > 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)
I am also for making it the default option to just take the arguments from the environment and so on. I think our build system should act like autotools does for someone who wants to build it on Linux. I just made the suggestion with the variable because I thought that you wanted it the over way around. > 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. I think when you build some program in scons the variable CPPFLAGS is given to the compiler. I am not an expert in this build system. > Additionally we should consider things like CFLAGS, CPPFLAGS, and CXXFLAGS. Yes we should do the same with CFLAGS, CXXFLAGS and LINKFLAGS (why is this named LINKFLAGS and not LDFLAGS?) > 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) Yes I think so too. I read into the philosophy of scons and they say that the build should be completely independed of the environment, which I see as a problem when you want to be flexible. Hauke
