Rob Browning writes: > Robert Graham Merkel <[EMAIL PROTECTED]> writes: > > > My suggestions would be to have something like g-scan which can scan > > a header file, locate marked enumerations, and generate the > > necessary C and Scheme code to automate the type conversion, as well > > as allow C functions that take that type to be wrapped. We would > > also generate some Scheme that converts between a symbolic and > > numeric representation. Writing the parser might be a pain, but > > provided we don't try anything too tricky (like use the preprocessor > > inside enumeration declarations) it should work. > > As far as I'm concerned, scanning headers (or C code at all) is a bad > idea. I've been down that road before, and unless you're willing to > write a full C preprocesor/parser and track the C language carefully, > you're bound to leave yourself open to messes you're better off not > expending your effort on. OK, point taken. > So I'd be much happier seeing g-wrap either: > > 1) allow you to define a C side function that handles the > translations from the C enums to ints, and g-wrap can call that > at startup to load a table. This would require you to keep that > function up to date as you modify the enumeration, but that's not > that much effort, and it would require you to include calls in > your guile side code to lookup the integer values when you need > them. > So what does this actually buy you, as composed to wrapping the type manually? From my understanding of g-wrap, not all that much. > 2) allow, for people who really want things automated and are > willing to accomodate g-wrap, the user to describe the > enumeration(s) in a simple spec file. gwrap would then use this > spec file to generate both the guile side code *and* an > appropriate C header snippet. This could be #included wherever > desired. This approach keeps us from having to parse C, and it > makes it impossible to have skew between the g-wrap and C sides. I do kind of prefer this. The down side is that it means that enums get taken out of header files, but you can generate *all* the code needed to deal with enumerations. However, is the pain of having a seperate spec file worth it? In a lot of cases, I think so. src/engine/query.h is probably a good example of where having a fully automated system would probably be rather worthwhile. -- ------------------------------------------------------------ Robert Merkel [EMAIL PROTECTED] ------------------------------------------------------------ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
