forked from kanzure/python-brlcad
-
Notifications
You must be signed in to change notification settings - Fork 1
/
ctypesgen.txt
54 lines (42 loc) · 2.49 KB
/
ctypesgen.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Here are some thoughts and workarounds about ctypesgen issues.
***************************
The following text describes a bug in ctypesgen which allows outputting of a declaration
without outputting all of it's dependencies.
Failure scenario: if X depends on Y, and Y depends on X, then what can happen is:
* X sets "can_include" to true;
* X will find Y as a requirement;
* Y sets "can_include" to true;
* Y will find X as a requirement -> but X has it's "can_include" True already, and won't be checked anymore;
* Y leaves "can_include" at True and be included;
* X continues to check dependencies, and finds one which fails;
* X sets "can_include" to False and won't be included
The net result: X is set to not included (correctly), but Y is set to be included ! At the end both will be
included, plus the invalid dependency of X which then makes the result fail (because syntax error for
example if the invalid dependency was a "long long" field).
For a quick-hack fix, add at the end of ctypesgencore.processor.pipeline#process:
def deny_include_desc(desc, processed):
if desc in processed:
return
if desc.included:
error_message("Skipping selected: {0}".format(desc))
desc.included=False
processed.add(desc)
for dep in desc.dependents:
deny_include_desc(dep, processed)
processed = set()
for desc in data.all:
if desc.include_rule=="never":
deny_include_desc(desc, processed)
This will avoid librt failing - but it has to be said that a good part of the library is not wrapped !
The real fix will be to make ctypesgen properly handle "typedef long long ..." !
***************************
Another issue with ctypesgen: if there is a name starting with '_' in a module which then is used as
dependency in another module, the dependent module will fail loading.
The reason is that the dependent module is importing the dependency with:
from dependeny_module import *
Now any name in dependency_module starting with a '_' is considered private and will not be imported,
and loading the dependent module will fail.
The names with "_" are likely private in the C libraries too, but unfortunately ctypesgen's dependency
checking will prune the intermediate public symbols if not explicitly included.
This was the case with __off_t and off_t in libbu - once off_t explicitly included, there's no need anymore
for __off_t in the dependent modules and loading them will work.