[libvirt] [PATCH] Centralize use of DEBUG macros
Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing. Thanks, Cole
On Thu, Oct 02, 2008 at 03:40:17PM -0400, Cole Robinson wrote:
Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing.
I guess the idea was to be able to turn debug on/off specifically per module, but since they all use the same macros now, sharing make sense to me, +1 Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thu, Oct 02, 2008 at 03:40:17PM -0400, Cole Robinson wrote:
Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing.
Yes, if someone can confirm one question
diff --git a/src/internal.h b/src/internal.h index d96504d..a3d48fa 100644 --- a/src/internal.h +++ b/src/internal.h @@ -85,6 +85,9 @@ extern int debugFlag; do { } while (0) #endif /* !ENABLE_DEBUG */
+#define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__) +#define DEBUG0(msg) VIR_DEBUG(__FILE__, "%s", msg) +
Will __FILE__ expand to the name of the file where the DEBUG macro is defined - ie internal.h, or will it expand to the name of the file where DEBUG() is called. Obviously the latter is what we need. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
On Thu, Oct 02, 2008 at 03:40:17PM -0400, Cole Robinson wrote:
Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing.
Yes, if someone can confirm one question
diff --git a/src/internal.h b/src/internal.h index d96504d..a3d48fa 100644 --- a/src/internal.h +++ b/src/internal.h @@ -85,6 +85,9 @@ extern int debugFlag; do { } while (0) #endif /* !ENABLE_DEBUG */
+#define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__) +#define DEBUG0(msg) VIR_DEBUG(__FILE__, "%s", msg) +
Will __FILE__ expand to the name of the file where the DEBUG macro is defined - ie internal.h, or will it expand to the name of the file where DEBUG() is called. Obviously the latter is what we need.
Daniel
I was worried about that as well, but testing the patch I posted confirmed that __FILE__ expands to where the macro is called from, so no change in existing behavior. Thanks, Cole
On Fri, Oct 03, 2008 at 10:56:02AM -0400, Cole Robinson wrote:
Daniel P. Berrange wrote:
On Thu, Oct 02, 2008 at 03:40:17PM -0400, Cole Robinson wrote:
Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing.
Yes, if someone can confirm one question
diff --git a/src/internal.h b/src/internal.h index d96504d..a3d48fa 100644 --- a/src/internal.h +++ b/src/internal.h @@ -85,6 +85,9 @@ extern int debugFlag; do { } while (0) #endif /* !ENABLE_DEBUG */
+#define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__) +#define DEBUG0(msg) VIR_DEBUG(__FILE__, "%s", msg) +
Will __FILE__ expand to the name of the file where the DEBUG macro is defined - ie internal.h, or will it expand to the name of the file where DEBUG() is called. Obviously the latter is what we need.
Daniel
I was worried about that as well, but testing the patch I posted confirmed that __FILE__ expands to where the macro is called from, so no change in existing behavior.
Great, ACK then Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Oct 03, 2008 at 03:53:25PM +0100, Daniel P. Berrange wrote:
On Thu, Oct 02, 2008 at 03:40:17PM -0400, Cole Robinson wrote:
Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing.
Yes, if someone can confirm one question
diff --git a/src/internal.h b/src/internal.h index d96504d..a3d48fa 100644 --- a/src/internal.h +++ b/src/internal.h @@ -85,6 +85,9 @@ extern int debugFlag; do { } while (0) #endif /* !ENABLE_DEBUG */
+#define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__) +#define DEBUG0(msg) VIR_DEBUG(__FILE__, "%s", msg) +
Will __FILE__ expand to the name of the file where the DEBUG macro is defined - ie internal.h, or will it expand to the name of the file where DEBUG() is called. Obviously the latter is what we need.
I do that in libxml2 debugging and I think that works as expected, I tried to check with gcc -E but failed :-\ Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Cole Robinson wrote:
Currently the DEBUG and DEBUG0 macros are duplicated in every file that uses them. This patch moves the macros to internal.h, removes the needless duplication, and now every file gets them for free. Seems to work as expected in my testing.
Thanks, Cole
This is committed now. Thanks, Cole
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Daniel Veillard