[dev] Building Iotivity 0.90 on ARM

2015-01-27 Thread Eric Feuvrier Danziger
> installed and either in or soft linked to /usr/local/lib. It just checks > for boost_program_options in the third party scons file, then fails the > check and exits. Any ideas of why this is? I have also tried > appendUnique-ing lib_env before it gets passed to conf [in the line conf = > Configure(lib_env) ]. > > > > I have never used scons before, so please use small words! > > > > Thanks, > > Eric > > > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150127/ba3986c1/attachment.html>

[dev] Bluetooth for Android in Connectivity Abstraction

2015-01-27 Thread Lankswert, Patrick
nts/20150127/ad65582c/attachment.html>

[dev] Building Iotivity 0.90 on ARM

2015-01-27 Thread Eric Feuvrier Danziger
lib_env before it gets passed to conf [in the line conf = >> Configure(lib_env) ]. >> >> >> >> I have never used scons before, so please use small words! >> >> >> >> Thanks, >> >> Eric >> > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150127/b3619124/attachment.html>

[dev] API Naming convention for IoTivity

2015-01-27 Thread Philippe Coval
On Tue, Jan 27, 2015 at 7:15 PM, Thiago Macieira wrote: > On Tuesday 27 January 2015 14:01:06 Lankswert, Patrick wrote: >> That is a good point. The naming convention should reflect the open source >> project and not necessarily the consortium. > > Here's another idea: let's just use "iot" for C++

[dev] Control Manager

2015-01-27 Thread Xu, Martin
> -Original Message- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Keane, Erich > Sent: Tuesday, January 27, 2015 9:49 > To: Macieira, Thiago > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Control Manage

[dev] Control Manager

2015-01-27 Thread Lankswert, Patrick
Thiago, I see your point. Pat -Original Message- From: Macieira, Thiago Sent: Tuesday, January 27, 2015 12:40 PM To: Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Control Manager On Tuesday 27 January 2015 15:25:16 Lankswert, Patrick wrote: > Thiago, > >

[dev] Control Manager

2015-01-27 Thread Keane, Erich
I come down with Thiago here. From a contributor's perspective, generated code is bad enough. However, if I have patch that I'm preparing to submit a pull request/code review for, and the project re-generates existing code, you've just made my patch likely unmergeable or even impossible to submit

[dev] Control Manager

2015-01-27 Thread Lankswert, Patrick
Thiago, I am not sure that we are disagreeing. I see only one public form, the contributed code. Consider the case, that I contribute a bundle of source that may or may not come from a code generator. If I contribute more source, does it matter whether it came from a generator or from hand? I

[dev] API Naming convention for IoTivity

2015-01-27 Thread J. Victor Martins
Quoting (on 2015-01-27 16:15:47): > On Tuesday 27 January 2015 14:01:06 Lankswert, Patrick wrote: > > That is a good point. The naming convention should reflect the open source > > project and not necessarily the consortium. > > Here's another idea: let's just use "iot" for C++ namespace, for inc

[dev] Control Manager

2015-01-27 Thread Lankswert, Patrick
John, Yes, I believe that this is the correct path. I want to make sure that we set clear precedence for moving forward. Pat -Original Message- From: Light, John J Sent: Tuesday, January 27, 2015 11:58 AM To: Lankswert, Patrick; uzchoi at samsung.com; Macieira, Thiago; iotivity-dev at

[dev] Control Manager

2015-01-27 Thread Light, John J
Pat, Having looked at the generated files in Control Manager, I now understand Uze's mails better, we may well be able to live with choice #2 (live with generated code, but never generate it again.) Here is why I believe this: * The generated code is quite readable, and I believe quite maintain

[dev] API Naming convention for IoTivity

2015-01-27 Thread Thiago Macieira
On Tuesday 27 January 2015 14:01:06 Lankswert, Patrick wrote: > That is a good point. The naming convention should reflect the open source > project and not necessarily the consortium. Here's another idea: let's just use "iot" for C++ namespace, for include path (/usr/include/iot/*) and for C pre

[dev] Control Manager

2015-01-27 Thread Lankswert, Patrick
Thiago, Let me add two thoughts to that. Let me apologize in advance if they lead down the rabbit hole. 1) If the generated code is accepted as the source, it needs to be reviewed. There is a lot of code. 2) You could run the generator again, BUT it is the responsibility of the contributor to

[dev] API Naming convention for IoTivity

2015-01-27 Thread Lankswert, Patrick
Thiago, That is a good point. The naming convention should reflect the open source project and not necessarily the consortium. Pat -Original Message- From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira Sent: Tue

[dev] Control Manager

2015-01-27 Thread Thiago Macieira
On Tuesday 27 January 2015 15:25:16 Lankswert, Patrick wrote: > Thiago, > > I am not sure that we are disagreeing. I see only one public form, the > contributed code. > > Consider the case, that I contribute a bundle of source that may or may not > come from a code generator. If I contribute more

[dev] Control Manager

2015-01-27 Thread Thiago Macieira
Hi Pat I don't agree with your conclusion #2. The requirement is that we provide the preferred form of modification. We can't have one form that some people prefer and another form for a few select people. If we accept this code, everyone must modify the same sources. The tool that originally

[dev] API Naming convention for IoTivity

2015-01-27 Thread Brad Nicholas
Not a member, but I believe claiming the primary name of a problem space like "iot" for a specific implementation will confuse developers - especially those that target applications for mixed requirements Brad Nicholas http://www.linkedin.com/in/bradn > On Jan 27, 2015, at 12:15 PM, Thiago Maci

[dev] Building Iotivity 0.90 on ARM

2015-01-27 Thread Eric Feuvrier Danziger
ic > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150127/b4bfeae4/attachment.html>

[dev] Control Manager

2015-01-27 Thread 최우제(Uze Choi)
Hi Pat, As like Jay's comment in the next mail from you, Tool is just what help the code made easily. If people can make the code without tool, I feel we don't need to mandate the tool contributed. We need to aware that the strict contribution policy can hamper the contribution activity. However,

[dev] API Naming convention for IoTivity

2015-01-27 Thread Thiago Macieira
Hello everyone There has been some discussion in a few review requests about the naming convention for our API. For historical reasons, the codebase started with "OC" prefix. Now, there are requests to change it to "OIC". So let's establish once and for all what our convention is and we'll begi

[dev] Building Iotivity 0.90 on ARM

2015-01-27 Thread Zhang, Caiwen
[in the line conf = Configure(lib_env) ]. I have never used scons before, so please use small words! Thanks, Eric -- next part -- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150127/b0fa8290/attachment.html>

[dev] Building Iotivity 0.90 on ARM

2015-01-27 Thread Kim, Jm
ed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150127/f131fed9/attachment.html>

[dev] Building Iotivity 0.90 on ARM

2015-01-27 Thread Zhang, Caiwen
part -- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150127/a063d13b/attachment.html>

[dev] Iotivity on Android

2015-01-27 Thread Evelyn Wang
Hi Luiz: Could you describe what kind of error you encounter for native part? Maybe I could help Have a nice day === Evelyn Wang MediaTek Inc. Office: +1-408-526-1899 Ext. 88414 Email: evelyn.wang at mediatek.com =