[pacman-dev] function tracing
I developed the following patch to print a message on function entry to trace program flow. Best part is that it's a #define so it can be undefined later to keep extra code out of the library/turned on with a --debug flag/whatever. The only odd thing I found was that the PM_* constants are in alpm.h instead of log.h so some .c's have to include 2 .h files for logging: one for the function _alpm_log (which should be public since pacman uses it) and the other for the constants. The constants should be moved to the log.h file. k
On 1/26/07, K. Piche <kevin.piche@cgi.com> wrote:
The only odd thing I found was that the PM_* constants are in alpm.h instead of log.h so some .c's have to include 2 .h files for logging: one for the function _alpm_log (which should be public since pacman uses it) and the other for the constants. The constants should be moved to the log.h file.
The goal here was to make it so that only alpm.h need be distributed with the library to use it. I think it's a worthy goal, IMO. Including an extra file really adds nothing to the end result, but REQUIRING an end user of libalpm to include yet-another adds some usage complexity. Just my opinion.
Oh, I totally agree with that - I confused pacman's log.h with libalpm's log.h. I thought pacman was including libaplm's log.h. Internally it's not a big deal to include two files. k On Tue, 2007-01-30 at 02:06 -0600, Aaron Griffin wrote:
On 1/26/07, K. Piche <kevin.piche@cgi.com> wrote:
The only odd thing I found was that the PM_* constants are in alpm.h instead of log.h so some .c's have to include 2 .h files for logging: one for the function _alpm_log (which should be public since pacman uses it) and the other for the constants. The constants should be moved to the log.h file.
The goal here was to make it so that only alpm.h need be distributed with the library to use it. I think it's a worthy goal, IMO. Including an extra file really adds nothing to the end result, but REQUIRING an end user of libalpm to include yet-another adds some usage complexity.
Just my opinion.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
participants (2)
-
Aaron Griffin
-
K. Piche