To change the LogLevel enum values to use a prefix was not hard but it is a really large change **6692** lines of code changed due to adding the OC_ prefix. ?I made the change and pushed it up to gerrit. If we are seriouse about making this sort of change then all we need is a JIRA ticket. ? Note I chose OC_ since it seems to be the more common prefix but it could really quickly be changed to something different.
https://gerrit.iotivity.org/gerrit/#/c/8457/ George On Thu, 2016-04-07 at 01:54 +0000, Antler, David A wrote: > Hi Jacob, > > Good prefix suggestions.??Yes, the Windows port has its own branch > named "windows-port" with changes open for review on > gerrit.??However, we have not published a change with the LogLevel > renaming. > > Best, David Antler > > -----Original Message----- > From: Gladish, Jacob [mailto:Jacob_Gladish at cable.comcast.com]? > Sent: Wednesday, April 6, 2016 1:45 PM > To: Antler, David A <david.a.antler at intel.com>; ???(Uze Choi) <uzchoi > @samsung.com>; 'Jon A. Cruz' <jon at joncruz.org>; Chang, Gene <gene.cha > ng at intel.com>; iotivity-dev at lists.iotivity.org > Subject: RE: [dev] Error using CSDK logger in objective-C > > I agree that the CSDK should use enum value names with names with > some type of prefix. I would suggest something equivalent to a c++ > namespace-like name. Possibly OC_LOGLEVEL_ or??OC_. The naming and > namespace in the c++ code is somewhat inconsistent, so I don't know > what the eventual namespace is supposed to be. > > Do you have a branch for the windows port?? > > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bo > unces at lists.iotivity.org] On Behalf Of Antler, David A > Sent: Wednesday, April 06, 2016 2:48 PM > To: ???(Uze Choi) <uzchoi at samsung.com>; 'Jon A. Cruz' <jon at joncruz.or > g>; Chang, Gene <gene.chang at intel.com>; iotivity-dev at lists.iotivity.o > rg > Subject: Re: [dev] Error using CSDK logger in objective-C > > I'm working on the Windows port, and what Jon said about our issue is > correct.??Our issue with ERROR occurs when we include <Windows.h>, so > we used an #undef ERROR hack.??See: > > ? https://gerrit.iotivity.org/gerrit/#/c/5509/16/resource/csdk/logger > /include/logger.h > > I think a CSDK should avoid name collisions.??A possible solution > would be to prepend the LogLevel enum values with a prefix (such as > "LL_") in all locations, if the maintainers would accept such a giant > change. > > We haven't noticed any issues with the DEBUG define, so I have no > requirements around that one. > > Best, David Antler > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bo > unces at lists.iotivity.org] On Behalf Of ???(Uze Choi) > Sent: Wednesday, April 6, 2016 1:23 AM > To: 'Jon A. Cruz' <jon at joncruz.org>; Chang, Gene <gene.chang at intel.co > m>; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Error using CSDK logger in objective-C > > In conclusion, what is the proposal with action plan? > > On the other hand, without modifying, low-level helper can resolve it > reversely. > We need the opinion from MS windows port developer. > > BR, Uze Choi > -----Original Message----- > From: Jon A. Cruz [mailto:jon at joncruz.org] > Sent: Wednesday, April 06, 2016 3:45 PM > To: ???(Uze Choi); Chang, Gene; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Error using CSDK logger in objective-C > > The windows build hit their main issue with the "ERROR" enum value. > > So far I believe we have avoided seeing the DEBUG issue much (aside > from > Tizen) due to the fact that we are not using a standard build system > but instead have rolled our own build system using a set of low-level > helpers. > > The work-around for ERROR was to just undef it and replace it in > logger.h. However... that could lead to some very bad and hard to > spot side-effects. Long term we definitely need to address this > correctly. > > On Tue, Apr 5, 2016, at 10:31 PM, ???(Uze Choi) wrote: > > > > Instead of the potential problem, specifically error happen in > > Windows? > > or Google test? > > I need the Chang answer for iOS. I'm curious Chang issue because, > > we? > > haven't experienced DEBUG keyword issue in iOS build here. > > > > BR, Uze Choi > > -----Original Message----- > > From: Jon A. Cruz [mailto:jon at joncruz.org] > > Sent: Wednesday, April 06, 2016 2:19 PM > > To: ???(Uze Choi); Chang, Gene; iotivity-dev at lists.iotivity.org > > Subject: Re: [dev] Error using CSDK logger in objective-C > > > > 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 > > > > -- > ? Jon A. Cruz > ? jon at joncruz.org > > _______________________________________________ > 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 > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
