Roman Yakovenko <roman.yakove...@gmail.com> writes:
> On Tue, Dec 15, 2009 at 12:35 AM, Nikolaus Rath <nikol...@rath.org> wrote:
>> Roman Yakovenko <roman.yakove...@gmail.com> writes:
>>>> Certainly all the exported symbols should already be available from
>>>> parsing the header file... Is it possible to omit the symbols file
>>>> and generate code based only on the headers?
>>>
>>> I don't think so( it didn't worked in my use case ) but you can try.
>>> Start to comment out code in ctypes_builder.py and post the result :-)
>>
>> I looked into the xml file created by gccxml and (at least in the case
>> of C code) it seems to contain all the information that's needed.
>>
>> I modified parsers.py to return an empty dict if no symbols_file is
>> provided:
>>
>> def merge_information( global_ns, fname, runs_under_unittest=False ):
>> """high level function - select the appropriate binary file parser and
>> integrates
>> the information from the file to the declarations tree. """
>> if fname is None:
>> return dict()
>>
>>
>> this seems to work partially. I can still export all the struct's, but I
>> no longer get any function exports. I can mark them as to be exported
>> without any error, but they don't show up in the generated code.
>>
>> Any idea?
>
> Yes. Py++ thinks that those functions are "private" and doesn't export
> them. You should dig father ( creators_factory/ctypes_creator.py ).
Ah, I think I'm beginning to understand the complexity. I have modified
the code so that it assumes that every defined function is also
exported:
def merge_information( global_ns, fname, runs_under_unittest=False ):
"""high level function - select the appropriate binary file parser and
integrates
the information from the file to the declarations tree. """
# If there is no shared library available for parsing, we just assume
# that all functions have been exported.
if fname is None:
return dict([ [f.name, f] for f in global_ns.calldefs() ])
but this actually includes lots of irrelevant stuff coming from other
included headers. You are right, parsing the actual shared library is
probably a good thing(tm).
I will concentrate on finding a good way to determine the path of a
shared library instead. At least under linux, it seems to be a good way
to parse the 'ldconfig -p' output...
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
