On Oct 12, 2016 3:28 PM, "Schulhof, Gabriel" <gabriel.schulhof at intel.com> wrote: > > Hey, all! > > I noticed that iotivity now ships a file called iotivity_config.h, > which seems to contain all the #define HAVE_THIS and #define > HAVE_THAT. Perhaps these defines should also be stored in that file, > so my application code will always be built with the same preprocessor > definitions as iotivity itself was built, without my having to do a > scons VERBOSE=1 and then having to harvest all the preprocessor > definitions from the various command lines, hoping that if I add those > definitions to my build scripts, the structures I use in my > application will be the same size and shape as the structures with > which iotivity was built. > > This lack of storing the build flags chosen by the user (most > importantly TCP_ADAPTER, ROUTING_EP, ROUTING_GW) in a config file that > is loaded from all the public headers (such as ocstack.h and > octypes.h) has been an unending source of problems! One of the most > wicked is that, if there's a mismatch, when on a client you perform a > resource discovery request, you get a response lacking an > OCDiscoveryPayload! > > So please! Either do not conditionally define public API or, if you > do, please do not make it necessary for application developers to > specify the preprocessor definitions on the build command line of > their applications. >
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? gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161012/95f84898/attachment.html>
