pyobjc 2.4 dropped support for bridgesupport files, that breaks wrappers for 3th party stuff

Issue #22 resolved
Ronald Oussoren
repo owner created an issue

Some people have their own framework wrappers, for frameworks that aren't supported by PyObjC or for in-house stuff. These people tend to use tools like gen_bridge_metadata tool generate bridgesupport files.

PyObjC 2.4 dropped support for bridgesupport files and that broke this scenario.

Therefore: reimplement the interface that PyObjC 2.3 used to load metadata files (in pure python, don't reintroduce the dependency on libxml)

Comments (20)

  1. Ronald Oussoren reporter

    Changeset ccbc9d56bd0b contains a partial implementation, the rest will be added soon.

    Most important missing bit: actual tests, those weren't present in 2.3 either but at in that version PyObjC used all features of the bridgesupport files itself.

  2. Ronald Oussoren reporter

    There will be a new release when I'm sure that bridgesupport files actually work. I'm currently working on unittests with a high enough coverage.

    These are entirely new tests, because pyobjc 2.3 didn't have explicit tests for the bridgesupport files but tested the support for them implicitly through the testsuites for the framework wrappers. PyObjC 2.4 no longer uses bridgesupport files itself, and therefore must have proper tests.

    I've already pushed a number of changes to the trunk while writing the testsuite, and there might be others.

  3. Ronald Oussoren reporter

    (Reply via

    The drop was not entirely intentional. I wanted to move pyobjc itself away from bridgesupport files to speed up the bridge. After that move I removed the C code for bridgesupport files to remove a dependency on libxml that caused some build problems. I had intended to reimplement the C code in python as I'm doing now, but never got around to it because I overestimated the amount of effort needed and in due time forgot about the missing code.

  4. Kentzo

    New parseBridgeSupport requires the bundle parameter. Previously I used the following syntax to add metadata for my framework:

    objc.parseBridgeSupport( IO_POWER_SOURCES_BRIDGESUPPORT, globals(), objc.pathForFramework("/System/Library/Frameworks/IOKit.framework") )

    What is the right syntax now? How can I make it compatible with PyObjC 2.3?

  5. Ronald Oussoren reporter

    The 'bundle' argument will be removed in the near future, it was the only way to get initFrameworkWrapper to work without changes to the C code of the bridge.

    I'm working on a patch that removes the 'bundle' parameter and should be able to push that out later today.

  6. Ronald Oussoren reporter

    It would be odd when I add a function back in for backward compatibility reasons and then require code changes to actually use it :-)

    I'm getting closer to code that I'm actually happy with, the code that extracts information from the XML document is now tested, I "just" have to add tests for the public APIs (parseBridgeSupport and initFrameworkWrapper).

  7. Ronald Oussoren reporter

    Changeset 0458bddf3f50 is the current tip and no longer has the 'bundle' argument.

    I've also added some placeholder tests for initFrameworkWrapper and parseBridgeSupport (the public API), those still have to be fleshed out.

  8. Ronald Oussoren reporter

    It looks like I can reproduce this using:

    import objc
    objc.initFrameworkWrapper('CoreFoundation', '/System/Library/Frameworks/CoreFoundation.framework', '', globals())

    The traceback in gdb is similar to the one in the crashreport.

  9. Kentzo

    I think I've found the problem: If bundle is not specified, name is never set, only c_name. Therefore PyObject* py_name = PyObjC_IdToPython(name); (bundle-variable.m #314) fails

  10. Log in to comment