Re: framework - Find/remove useless ifdefs and dead code within them

On 11/13/2012 12:06 AM, Marcos Souza wrote:
> 2012/11/10 Matúš Kukan <matus.kukan@gmail.com
> <mailto:matus.kukan@gmail.com>>
>     On 10 November 2012 17:51, Marcos Souza <marcos.souza.org@gmail.com
>     <mailto:marcos.souza.org@gmail.com>> wrote:
>      > Some days ago, I developed a script that can show to us all
>     ifdefs that
>      > don't have a "#define".
>      >
>      > After run this script in the "framework" dir, I get this list:
>      >
>      > ifdef ENABLE_COMPONENT_SELF_CHECK without #define. This can be
>     removed?
>      > ifdef DBG_UTIL without #define. This can be removed?
>      > ifdef fpf without #define. This can be removed?
>      > ifdef fpc without #define. This can be removed?
>      > ifdef ENABLE_SERVICEDEBUG without #define. This can be removed?
>      > ifdef ENABLE_TARGETINGDEBUG without #define. This can be removed?
>      > ifdef ENABLE_REGISTRATIONDEBUG without #define. This can be removed?
>      > ifdef ENABLE_PLUGINDEBUG without #define. This can be removed?
>      > ifdef ENABLE_MUTEXDEBUG without #define. This can be removed?
>      > ifdef ENABLE_FILTERDBG without #define. This can be removed?
>      > ifdef ENABLE_EVENTDEBUG without #define. This can be removed?
>      > ifdef ENABLE_GENERATEFILTERCACHE without #define. This can be
>     removed?
>      >
>      > This is the output of my script. I belive DBG_UTIL is defined in
>     an other
>      > way (a lot of code within this ifdefs around the LO) but I didn't
>     notice any
>      > define explicitly.
>
>     git grep DDBG_UTIL points to solenv/gbuild/gbuild.mk
>     <http://gbuild.mk>, where also
>     others are defined (probably not from this list).
>     But for some, it's not that obvious and grepping for D<name> does not
>     help, see for example gb_Helper_define_if_set.
>
> But, in this case, I will try to verify these D<ifdef name> too, now
> that I know that defines could be used in the build. Do you believe this
> is a valid approach to do before talk with the list about these ifdefs?
>
> I will ignore DBG_UTIL in my script and others defines within
> solenv/gbuild/gbuild.mk <http://gbuild.mk> with -D<macro name>
>
> List,
>
> What you can say about these other macros? After your comments, I
> believe we can get ride of a lot of code, and make the LO better without
> all junk that we can found.

At least from the macros' names, many of them appear to be intended to 
enable specific debug information.  So instead of blindly removing the 
code covered by them, it might be better to turn them into calls to the 
new sal/log.hxx functionality instead.  For example, the calls to 
LOG_ASSERT2 covered by #ifdef ENABLE_MUTEXDEBUG in 
framework/inc/threadhelp/fairrwlock.hxx and 
framework/source/fwi/threadhelp/transactionmanager.cxx should probably 
be rewritten as unconditional calls to SAL_WARN.

Stephan