From: Anthony Liguori <anthony@codemonkey.ws>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Avi Kivity <avi@redhat.com>,
qemu-devel@nongnu.org, Stefan Weil <sw@weilnetz.de>
Subject: Re: [Qemu-devel] [PATCH v2 0/4] GTK-DOC build integration (v2)
Date: Wed, 14 Dec 2011 15:08:21 -0600 [thread overview]
Message-ID: <4EE91045.9070109@codemonkey.ws> (raw)
In-Reply-To: <CAJ+F1CKNMGk6qikGNiyPgxfs6EpakTOxhm9V3HTHFUeyfE=0_Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On 12/14/2011 02:54 PM, Marc-André Lureau wrote:
> Hi
>
> On Wed, Dec 14, 2011 at 9:01 PM, Anthony Liguori<aliguori@us.ibm.com>wrote:
>
>> For v2, I'm relying on a fork of gtk-doc that removes the underscore
>> requirements. I really hate to do this but I like it better than not
>> having
>> documentation. I'm poking in the gtk+ community to see if there's an
>> upstream
>> compromise possible.
>>
>
> Can you point out a discussion/bug, What is the "underscode requirements"?
The following is what I need to make it work. I'm still trying to find out
where to even have this discussion.
Regards,
Anthony Liguori
>
> thanks
>
[-- Attachment #2: 0001-Don-t-assume-struct-names-are-prefixed-with-_.patch --]
[-- Type: text/x-patch, Size: 4279 bytes --]
>From f3894f803b417bbfc19d282fda348ff9e0d6ce26 Mon Sep 17 00:00:00 2001
From: Anthony Liguori <aliguori@us.ibm.com>
Date: Wed, 14 Dec 2011 13:23:12 -0600
Subject: [PATCH] Don't assume struct names are prefixed with '_'.
---
gtkdoc-mkdb.in | 4 ++--
gtkdoc-scan.in | 18 +++++++++---------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/gtkdoc-mkdb.in b/gtkdoc-mkdb.in
index 339203e..096266d 100755
--- a/gtkdoc-mkdb.in
+++ b/gtkdoc-mkdb.in
@@ -1489,7 +1489,7 @@ sub OutputStruct {
my $decl_out = "";
if ($declaration =~ m/^\s*$/) {
#print "Found opaque struct: $symbol\n";
- $decl_out = "typedef struct _$symbol $symbol;";
+ $decl_out = "typedef struct _?$symbol $symbol;";
} elsif ($declaration =~ m/^\s*struct\s+\w+\s*;\s*$/) {
#print "Found opaque struct: $symbol\n";
$decl_out = "struct $symbol;";
@@ -1535,7 +1535,7 @@ sub OutputStruct {
# empty struct declaration.
if ($decl_out eq "") {
if ($has_typedef) {
- $decl_out = "typedef struct _$symbol $symbol;";
+ $decl_out = "typedef struct _?$symbol $symbol;";
} else {
$decl_out = "struct $symbol;";
}
diff --git a/gtkdoc-scan.in b/gtkdoc-scan.in
index 04bfb4a..b435a20 100755
--- a/gtkdoc-scan.in
+++ b/gtkdoc-scan.in
@@ -461,7 +461,7 @@ sub ScanHeader {
# ENUMS
- } elsif (s/^\s*enum\s+_(\w+)\s+\{/enum $1 {/) {
+ } elsif (s/^\s*enum\s+_?(\w+)\s+\{/enum $1 {/) {
# We assume that 'enum _<enum_name> {' is really the
# declaration of enum <enum_name>.
$symbol = $1;
@@ -483,7 +483,7 @@ sub ScanHeader {
# STRUCTS AND UNIONS
- } elsif (m/^\s*typedef\s+(struct|union)\s+_(\w+)\s+\2\s*;/) {
+ } elsif (m/^\s*typedef\s+(struct|union)\s+_?(\w+)\s+\2\s*;/) {
# We've found a 'typedef struct _<name> <name>;'
# This could be an opaque data structure, so we output an
# empty declaration. If the structure is actually found that
@@ -492,11 +492,11 @@ sub ScanHeader {
@TRACE@("$structsym typedef: $2");
$forward_decls{$2} = "<$structsym>\n<NAME>$2</NAME>\n$deprecated</$structsym>\n"
- } elsif (m/^\s*(?:struct|union)\s+_(\w+)\s*;/) {
+ } elsif (m/^\s*(?:struct|union)\s+_?(\w+)\s*;/) {
# Skip private structs/unions.
@TRACE@("private struct/union");
- } elsif (m/^\s*(struct|union)\s+(\w+)\s*;/) {
+ } elsif (m/^\s*(struct|union)\s+_?(\w+)\s*;/) {
# Do a similar thing for normal structs as for typedefs above.
# But we output the declaration as well in this case, so we
# can differentiate it from a typedef.
@@ -504,7 +504,7 @@ sub ScanHeader {
@TRACE@("$structsym: $2");
$forward_decls{$2} = "<$structsym>\n<NAME>$2</NAME>\n$_$deprecated</$structsym>\n";
- } elsif (m/^\s*typedef\s+(struct|union)\s*\w*\s*{/) {
+ } elsif (m/^\s*typedef\s+(struct|union)\s*_?\w*\s*{/) {
$symbol = "";
$decl = $_;
$level = 0;
@@ -659,11 +659,11 @@ sub ScanHeader {
# STRUCTS
- } elsif (m/^\s*struct\s+_(\w+)\s*\*/) {
+ } elsif (m/^\s*struct\s+_?(\w+)\s*\*/) {
# Skip 'struct _<struct_name> *', since it could be a
# return type on its own line.
- } elsif (m/^\s*struct\s+_(\w+)/) {
+ } elsif (m/^\s*struct\s+_?(\w+)/) {
# We assume that 'struct _<struct_name>' is really the
# declaration of struct <struct_name>.
$symbol = $1;
@@ -676,9 +676,9 @@ sub ScanHeader {
# UNIONS
- } elsif (m/^\s*union\s+_(\w+)\s*\*/) {
+ } elsif (m/^\s*union\s+_?(\w+)\s*\*/) {
# Skip 'union _<union_name> *' (see above)
- } elsif (m/^\s*union\s+_(\w+)/) {
+ } elsif (m/^\s*union\s+_?(\w+)/) {
$symbol = $1;
$decl = $_;
$level = 0;
--
1.7.4.1
next prev parent reply other threads:[~2011-12-14 21:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 20:01 [Qemu-devel] [PATCH v2 0/4] GTK-DOC build integration (v2) Anthony Liguori
2011-12-14 20:01 ` [Qemu-devel] [PATCH v2 1/4] memory: make memory API parsable by gtkdoc-scan (v2) Anthony Liguori
2011-12-15 9:28 ` Kevin Wolf
2011-12-15 13:25 ` Anthony Liguori
2011-12-14 20:01 ` [Qemu-devel] [PATCH v2 2/4] docs: add build infrastructure for gtkdocs (v2) Anthony Liguori
2012-03-12 20:48 ` Eduardo Habkost
2012-03-12 23:37 ` Andreas Färber
2011-12-14 20:01 ` [Qemu-devel] [PATCH v2 3/4] memory: update documentation to be in gtk-doc format Anthony Liguori
2011-12-14 20:01 ` [Qemu-devel] [PATCH v2 4/4] memory: move header into include/ and add to QEMU docs Anthony Liguori
2011-12-14 20:54 ` [Qemu-devel] [PATCH v2 0/4] GTK-DOC build integration (v2) Marc-André Lureau
2011-12-14 21:08 ` Anthony Liguori [this message]
2011-12-15 5:22 ` Andreas Färber
2011-12-15 9:32 ` Stefan Weil
2011-12-15 10:04 ` Daniel P. Berrange
2011-12-15 10:29 ` Stefan Weil
2011-12-15 11:36 ` Andreas Färber
2011-12-15 11:46 ` Kevin Wolf
2011-12-15 10:21 ` Kevin Wolf
2011-12-18 12:00 ` Stefan Weil
2012-03-12 21:03 ` Lluís Vilanova
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE91045.9070109@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.