Although I've not had as much recently as I'd like hashing things out here on the list, it still feels like the right place to ask questions.
Through 2017 there was an effort to make build warnings have some meaning - many were rooted out and fixed, the flags during builds were adjusted, etc. The linux builds relatively recently were told to actually fail if there are warnings, although the default state of this setting met with a bit of trouble, and there's a patch pending for the 1.3 branch to flip it back to default to off, rather than on: https://gerrit.iotivity.org/gerrit/#/c/23963/ In any case, for as long as gcc has been around, version bumps have brought greater strictness. gcc7 is widespread now and it followed this tradition, nothing new - and as the C++ standards (in particular) evolve, it is even what you would want, to follow those standards. Ubuntu LTS 18.04 will have gcc 7.2. gcc7 won't build iotivity with these new settings, so there are now some questions about warnings. Backgrounder: 1. linux builds set the flag -Wextra in CCFLAGS, which turns on additional warnings for both C and C++. 2. linux builds set the flag -Werror in CFLAGS, which cause warnings to be treated as errors for C, but not for C++. 3. External library builds (extlibs) remove the -Werror flag, since our builds should not fail on warnings in someone else's code. If necessary we can propose fixes to upstream, but they should come in that way, not from local patching which we then have to try to maintain. 4. One external library, tinycbor, does not receive the treatment described in 3, as the SConscript there just makes sure the files are in place and then adds the files to a variable which is picked up later, so there are quite a few warnings from this library, and due to the context of the build these are fails (there's also a move to uplift the external library since the warnings are believed fixed there, but apparently there are problems at the moment) So that leaves serveral questions about warnings: A. as described in (2), -Werror applies currently only to C code. Should this flag be moved to CCFLAGS so it applies to both languages? B. how to handle the tinycbor warnings, since the discussion in IOT-2539 does not apply this this case? C. Deprecated language features generate a warning, which now causes errors. In particular, C++ exception syntax is changing: service/notification/cpp-wrapper/consumer/inc/NSProvider.h:143:69: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated] (there is a jira ticket on that from a while back, IOT-2782) D. a resource property is used as a flag, but gcc no longer likes that usage: resource/src/OCResource.cpp:227:14: warning: enum constant in boolean context [-Wint-in-bool-context] The usage that causes the complaint always looks like: if (!OC_SECURE) where OC_SECURE is an enumerator in the OCResourceProperty enumeration. E. Deprecated usage in unittests, based on our own deprecation of two functions b64Encode and b64Decode (using the new OC_DEPRECATED stuff). In fact we deprecated the whole header base64.h. So this deprecation is causing build fails... was that actually intended? Or is the fail part premature? resource/csdk/security/unittest/base64tests.cpp:103:79: warning: 'B64Result b64Encode(const uint8_t*, size_t, char*, size_t, size_t*)' is deprecated: Please use mbedtls implementation [-Wdeprecated-declarations] Since the unit test is testing the behavior of this deprecated code, this creates an interesting dilemma: as long as the code still exists, it should have tests, no? but the test will cause build fails under the current scenario. So meta-question: with the combination of flags, use of deprecated features causes warnings which we want; warnings cause errors which we want to get people to fix the warnings; but the combination seems to cause something we don't want. We can add a flag to have the deprecation warning go away, which will make the build fails go away, but then we don't get the warnings. I don't think there's a combination of gcc options which say "fail on warnings, except on deprecation warnings". So what is the right way forward on deprecation? _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
