GNOME Bugzilla – Bug 64714
[PATCH] glib-mkenums parse error
Last modified: 2004-12-22 21:47:04 UTC
with an enum defined as such typedef enum { BLAH, BLAH1 } /* the newline causes the problem */ blahenum; glib-mkenums fails with a parse error ... the following patch fixes it. May I commit? Index: glib-mkenums.in =================================================================== RCS file: /cvs/gnome/glib/gobject/glib-mkenums.in,v retrieving revision 1.3 diff -u -p -r1.3 glib-mkenums.in --- glib-mkenums.in 2001/10/29 16:13:36 1.3 +++ glib-mkenums.in 2001/11/16 17:56:39 @@ -27,6 +27,7 @@ sub parse_trigraph { sub parse_entries { my $file = shift; my $file_name = shift; + my $looking_for_name = 0; while (<$file>) { @@ -46,6 +47,13 @@ sub parse_entries { next if m@^\s*$@; # print STDERR "xxx $_\n"; + + if ($looking_for_name) { + if (/^\s*(\w+)/) { + $enumname = $1; + return 1; + } + } # Handle include files if (/^\#include\s*<([^>]*)>/ ) { @@ -74,6 +82,12 @@ sub parse_entries { return 1; } + if (/^\s*\}/) { + $enumindex++; + $looking_for_name = 1; + next; + } + if (m@^\s* (\w+)\s* # name (?:=( # value
Well, this isn't the most elegant way of handling this ... I'd probably try to unify the handling of this with the handling of the normal close. But looks like it will work. Go ahead and commit.
No, its certainly not elegant - its a passable quick fix :-) I've committed anyway. Oh, and if you're wondering why I didn't just fix my headers, the problem occurs generating enums from orbit-idl generated headers ... And the problem there is not orbit-idl, its indent .. :/