I just ran into this problem again today myself, so would like a solution, 
whatever it is.
Is there a JIRA ticket tracking this?

-----Original Message-----
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:[email protected]] On Behalf Of Schulhof, Gabriel
Sent: Thursday, October 13, 2016 12:01 AM
To: Gregg Reynolds <dev at mobileink.com>
Cc: iotivity-dev <iotivity-dev at lists.iotivity.org>
Subject: Re: [dev] ROUTING default

Hey!

> fwiw, there is another option, which is to not build iotivity as a library.
> the only reason to make a lib is so that multiple clients can use it.  
> how important is that for iot?

On Linux, if you run scons, you will get both archives and a shared object, so 
I could link either statically or dynamically. Yet no matter how I link to 
iotivity, the problem is that the object files inside both the archives and the 
shared libraries were compiled thinking that, for example, the struct OCDevAddr 
has a member named routeData, whereas my application will be compiled thinking 
that there is no such member, because I didn't know to pass the appropriate 
preprocessor defines to my build system. The problem of the mismatched 
preprocessor defines arises if I use scons at all. So, the real alternative is 
to not use scons, but to build the source files directly, using the 
application's build process, and  - which is a nightmare, because you end up 
duplicating half the contents of the scons-related files, and now you have to 
keep your build system in sync with scons as you move through the versions - 
all because scons'
choice of preprocessor directives is not stored in a public header.

Besides, in the specific case of ROUTING_EP vs. ROUTING_GATEWAY it sounds like 
one of the two absolutely must be defined. In addition, I looked through the 
code, and all the #if statements relating to these two defines go like this:

#if defined (ROUTING_GATEWAY) || defined (ROUTING_EP)

So, is there even a point having these two definitions? Of course one of them 
will always be defined, assuming nobody breaks the scons configuration! Why not 
just unconditionally declare everything that's enclosed in a condition of the 
above form?

Cheers!



Gabriel
_______________________________________________
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

Reply via email to