Yes. The problem is that whoever wrote the logger code chose a poor name that is commonly used for other purposes.
'DEBUG' is so common for a build of release vs. debug that it has been the de facto standard for decades. We need to change the logger code to no longer hijack potentially colliding names. In the big-picture the problem is that a code subsystem that was intended to be used throughout other code did not safely prefix its names. We need to try to ensure that all names are safe. So the short-term fix should not be to force other code to stop using "DEBUG" because the logger wants it, but to instead fix the logger to no longer 'steal' the "DEBUG" name. On Tue, Apr 5, 2016, at 09:51 PM, ???(Uze Choi) wrote: > As a fact, DEBUG is used for build MACRO and enum for LOG together. > > Chang and Jon could you make it clear that your problem and concern is > related with these two or other reserved keyword. > (iOS, Windows and Google Test) > > If the problem is related with DEBUG MACRO in build script and source > code. We can fix it relatively easy. > Today I searched DEBUG keyword from whole IoTivity source code for > #ifdef as follows. > Debug.h (extlibs\tinydtls):# ifndef DEBUG > Dtls-client.c (extlibs\tinydtls\examples\contiki):#ifndef DEBUG > Dtls-server.c (extlibs\tinydtls\examples\contiki):#ifndef DEBUG > Debug.c (resource\csdk\connectivity\lib\libcoap-4.1.1):# ifndef DEBUG > Net.c (resource\csdk\connectivity\lib\libcoap-4.1.1):# ifndef DEBUG > To avoid the conflict, change the DEBUG definition from MACRO for #ifdef > from upper source code and build script looks easiest way. (e.g > BUILD_DEBUG) > > else if your concern and problem is related with other reserved keyword > beyond these two definitions, > we need to think about it again as Jon suggested. Redefine the enum with > prefix. > > Let's clarify the problem first. > > BR, Uze Choi > -----Original Message----- > From: Jon A. Cruz [mailto:jon at joncruz.org] > Sent: Wednesday, April 06, 2016 12:50 PM > To: ???(Uze Choi); Chang, Gene; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Error using CSDK logger in objective-C > > Yes. Enum values should be cleaned up a bit. I know during certain > sections initial code reviews called for such prefixing. However, I think > the logging code was done very early on. > > The Windows branch also is hitting problems with these. Additionally use > of non-prefixed enums and/or macros was one aspect of Google Test that > many found problematic. So it's not a completely unique problem, but > there are ways to fix it. > > On Mon, Apr 4, 2016, at 05:43 PM, ???(Uze Choi) wrote: > > As like done in Tizen platform. > > DLOG_ prefix looks best way to do. > > > > #ifdef __TIZEN__ > > typedef enum { > > DEBUG = DLOG_DEBUG, > > INFO = DLOG_INFO, > > WARNING = DLOG_WARN, > > ERROR = DLOG_ERROR, > > FATAL = DLOG_ERROR > > } LogLevel; > > #else > > typedef enum > > { > > DEBUG = 0, INFO, WARNING, ERROR, FATAL } LogLevel; #endif > > > > Temporary you can switch code for iOS build as like this definition. > > However, holistic perspective duplication need to be avoid changing > > enum as like this. > > > > BR, Uze Choi > > -----Original Message----- > > From: iotivity-dev-bounces at lists.iotivity.org > > [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Chang, > > Gene > > Sent: Tuesday, April 05, 2016 5:19 AM > > To: iotivity-dev at lists.iotivity.org > > Subject: [dev] Error using CSDK logger in objective-C > > > > I am working on using iotivity for Mac and iOS and am having a compile > > problem using logger.h. I?m trying to use the rdpayload.h headers to > > do some cbor processing in an objective-C SDK. It looks like the > > problem I?m running into is in the LogLevel enum DEBUG declaration. > > > > I think the problem is that on Xcode for Mac/iOS (and probably also VS > > for windows) DEBUG is already #defined and is causing a conflict in > > the global namespace for the Iotivity CSDK. Has there been any > > thought to prefixing the enum declarations to prevent namespace conflicts? > > > > Thanks. > > > > Gene Chang > > Support and Enablement Lead > > Intel > > gene.chang at intel.com<mailto:gene.chang at intel.com> > > > > This e-mail and any attachments are confidential and may be subject to > > legal or some other professional privilege. They are intended solely > > for the attention and use of the named addressee(s). > > If you are not the named addressee(s) you must not use, disclose, > > retain or reproduce all or any part of the information contained in > > this e-mail or any attachments. > > Any unauthorized use or disclosure may be unlawful. If you have > > received this e-mail by mistake, please inform the sender immediately > > and delete it and all copies from your system and destroy any hard copies > > of it. > > > > _______________________________________________ > > 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 > > > -- > Jon A. Cruz > jon at joncruz.org > -- Jon A. Cruz jon at joncruz.org
