[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1209610 - /subversion/trunk/subversion/libsvn_subr/debug.c

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sat, 7 Jan 2012 22:57:58 +0100

On Sat, Jan 7, 2012 at 7:14 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Jan 7, 2012 8:39 AM, "Johan Corveleyn" <jcorvel_at_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 ...

Received on 2012-01-07 22:58:55 CET

This is an archived mail posted to the Subversion Dev mailing list.