[pacman-dev] do we need debug in alpm_depcmp?

[Dan McGee]

On Nov 19, 2007 12:33 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > On Nov 19, 2007 6:55 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> > > So in short- submit a patch for *one* feature at a time, and justfiy
> > > it in the commit message. Don't try to sneak things by. I do think
> > > this may be a valid complaint though.
> >
> > Even better? How about something similar to:
> >
> > #ifdef PACMAN_DEBUG
> > #    define DEBUG_LOG(...) _alpm_log(PM_LOG_DEBUG, __VA_ARGS__)
> > #else
> > #    define DEBUG_LOG(x)
> > #endif
> >
> > Then just:
> > s/_alpm_log(PM_LOG_DEBUG,/DEBUG_LOG(/g
> >
> > This way we could simply get rid of all debugging if we wanted to.
> > Then you have both a useful version for debugging, and a "snappy"
> > version that saves 1 or 2 seconds without having to output anything.
>
> I like this idea, but:
> What about user feedbacks? We will ask them to download a debugging-enabled
> version of pacman?
>
> Bye, ngaba

Remember we have different kinds of debugging once you start looking
at compile-time parameters. By this I mean PACMAN_DEBUG (either on or
off), and the debug flag (set by --debug). Right now PACMAN_DEBUG is
never used on the libalpm side, which I think is smart.

I think Nagy makes a good point- any debugging we have that is always
compiled in should be O(1) so that we aren't slowing down the program
95% of the time when people aren't using debug.

It may make more sense to reintroduce some sort of handle->debug
option back into libalpm. We could then wrap expensive calls inside an
if(handle->debug), as well as having alpm_log never even calling the
callback function if handle->debug is disabled for PM_LOG_DEBUG
messages.

Proposed API change:
alpm_option_debug(int debug); (with a default to off)

Thoughts? This would allow us to always get full debug reports from users.

By the way, I'm not sure I like timestamping the debug logs when
PACMAN_DEBUG is defined- it makes it a lot more of a pain to diff
debug logs from good and bad runs of the same command. I know Nagy
just brought this issue up and was going to implement it before he
knew it was already there. Can someone explain the benefits to me?

-Dan