Hi Gabriel, I totally agree with you. According to preprocessor directives, API (signature and data structure) change happening in the same header file should be strictly prohibited.
As iotivity.git gets bigger (now approximately 300k SLOC), developer cannot remember and track the whole preprocessor flag. I think maintainer should follow this rule with priority rather than other consideration. Exactly related Jira ticket does not exist, however, conceptually preference is requested and registered Jira. Please see the list corresponding to this issue as below. IOT-1182 <https://jira.iotivity.org/browse/IOT-1182> Do not make API config dependent IOT-1073 Platform-specific ifdefs littering the code makes portability cumbersome and error prone BR, Uze Choi From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Abhishek Sharma Sent: Tuesday, October 25, 2016 3:40 PM To: Dave Thaler via iotivity-dev Subject: Re: [dev] ROUTING default I tried addressing this multiple times but discussions have gone nowhere. I have added a patch here that will prevent this problem in future: https://gerrit.iotivity.org/gerrit/#/c/13639/ --------- Original Message --------- Sender : Dave Thaler via iotivity-dev <iotivity-dev at lists.iotivity.org> Date : 2016-10-25 04:22 (GMT+5:30) Title : Re: [dev] ROUTING default 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 _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161025/ff4f3874/attachment.html>
