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
