|
Guest
|
a problem exists in general:
one like me does not want to go through the effort of writing glue code, or
even function definition files.
please tolerate my subsequent abuse of the term 'idl'... I mean just the
general concept of a file defining an interface to something, rather than
any particular format (eg: like corba idl's or whatever...).
header mining traditionally presents problems, eg, there can be lots of
system-dependent bits, weird types, ...
similarly, one does not necissarily want to, say, see into many structs, but
instead just wants to treat them as a pointer value, ...
then I had started thinking of a misc idea, eg:
what if for code, I could effectively generate prototypes with special type
names, and use a tool sort of like my autoheader tool to mine info for the
ffi?
this presented another problem:
going and altering all my functions to use special type names would be a
major pita, and still doesn't help much with the ffi.
next thought:
info could be given effectively telling the miner tool to rename types, eg,
'char *' to 'String_MT' (or whatever convention I decide to use for this).
in this way I could handle at least all the basic types, and possibly
functions with unknown types can just be ignored.
apart from the typically huge amount of preprocessor stuff, I could almost
run a prototype miner on the headers, and do this sort of rename,
effectively giving a partial idl.
the issue, however, remains that headers are heavily macro'ed. I can run
them through the preprocessor, but the problem is that there is little
expectation for how things are going to be broken up (eg: my existing
prototype minor makes a few assumptions), and there could be lots of
unrecognized extra crap (eliminating "sane" parsing).
so my next thought:
I can use the preprocessed headers, and what I know about the types, to
actually try to mine the headers. eg: I can scan the headers in token space,
and process anything that looks like a valid prototype.
TYPE=<typename> '*'*
ARGS=<TYPE> [<name>][, <ARGS>]
<TYPE> [<some-gcc-crap>] <name>(<ARGS>)
where typename is one of the predefined typenames (presumably the
indirection could would be specified, eg, allowing 'char', 'char *', and
'char **' to be assigned different typenames).
now, given the problematic nature of all this, likely the tool is going to
have to be fairly well supervised, so I will likely be sitting around trying
to mine idl's and using the idls for any subsequent code generation.
likely also it may be necessary to edit the generated idls to prune out any
crap that got added in that shouldn't have.
possibly lame:
I may actually write the input data for the miner as a few c files. this
makes invoking the preprocessor possibly with special options or such a
little more straightforward.
so, first stage: 'gcc -E -dD' or such.
ok, examiming some processed headers, there is still some crap the tool
would have to ignore. however, it is looking like I may be able to actually
operate in a manner similar to my previous miner, vs actually having to
process the file as a token stream (eg: regular use of linebreaks, ...).
normal code passes through pretty clean, that is good. of course, comments
are removed, so I may effectively have to abuse c.
as a result, the second stage (actually fed into the miner), will consist of
the preprocessed headers and commands all mixed up, and it will do whatever
and try to generate output.
similarly, this may make embedding extra data to be sent to the generated
idl's easier, this would include, eg, some wrapper code or similar.
I may try this (likely sometime tommorow or later), and I may comment on it
if I have any real success...
if I have success this may possibly have a general use (eg: a practical
means to generate interface definitions for system libraries...).
interesting could be trying to come up with tools to convert them to forms
usable by other ffi's...
any comments?... |
|
|
