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.

HTH and TIA,



Gabriel

Reply via email to