On Sat, Jan 7, 2012 at 10:57 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Sat, Jan 7, 2012 at 7:14 PM, Greg Stein <gst...@gmail.com> wrote: >> >> On Jan 7, 2012 8:39 AM, "Johan Corveleyn" <jcor...@gmail.com> wrote: >>>... >> >>> BTW, I noticed that, before r1209610, my release build was failing for >>> another reason: >>> >>> ..\..\..\subversion\libsvn_subr\debug.c(111): error C4013: 'SVN_DBG' >>> undefined; assuming extern returning int >> >> Right. SVN_DBG should not be committed, or the usages should be wrapped with >> #ifdef SVN_DEBUG. >> >>> >>> (this started happening after r1209598, which said "Add a debug macro >>> to print a prop hash." --- before r1209598 all was ok) >>> >>> I assumed that was the reason for r1209610: to make the builds, which >>> didn't define SVN_DEBUG (release builds), working again after r1209598 >>> broke them. Except that it doesn't fix the problem for the Windows >>> compiler / linker (cf. danielsh's extractor.py pointer). >>> >>> So, if we just revert r1209610, the (release) builds will fail again >>> for this other reason. >> >> I think the functions should *always* exist, so that we don't have to mess >> with DLLs that have different sets of entrypoints based on how they were >> compiled. Madness. >> >> My recommendation is to move the #ifdef guards to the function content. Just >> make them noops in release builds. Then you can mix/match debug/release no >> problem. > > Ah yes, I'm beginning to understand. > > Actually, the only problematic function is the new-in-r1209598 > svn_dbg__print_props, and then only the single line with SVN_DBG in > the for-loop. So I see 3 options for the scope of #ifdef guard: > > 1. as small as possible: just around line 114 (the single SVN_DBG). > > 2. a little larger: around the entire body of svn_dbg__print_props. > > 3. still larger: around all of the individual bodies of > svn_dbg__preamble, svn_dbg__printf and svn_dbg__print_props. > > > Hmmm, this is not my forte, but intuitively I'd go for option 2. Any > opinions? Or other solutions? Can svn_dbg__print_props avoid the use > of SVN_DBG? I guess not ...
Ok, I went for option 2, in r1228957. If anyone thinks this should be fixed in another way, feel free to do so ... Cheers, -- Johan
