Just try to compile my project with foreign code and encounter this error when compiling in XCode
Error: no member named 'uObjC' in the global namespace
After I check the code, it seems that it’s coming from fuse generated source code. I have to add #include "uObjC.String.h" manually in generated source code through XCode. This issue was not the case in previous build (last time I try to compile this code is with build 0.21), and currently I’m using latest build (0.27)
Can either of you share your code? I just made a minimal app with some foreign code but didn’t run into this. What should happen (and it does for me) is that any generated code that uses foreign code should get the uObjC.Foreign.h include (which transitively includes uObjC.String.h), so perhaps you’re running into some problem with that mechanism.
Ah, it’s in an external Objective-C++ (.mm) source file, and not in an Uno file. To use UXL macros (the @{...} bit in your code) to call back to Uno from such a file you have to add the uObjC.Foreign.h include yourself, as mentioned in the docs.
at the beginning of the .mm file, but Xcode shows the same error (uObjC.h file not found).
I am using this example: https://github.com/bolav/fuse-camerapanel, imported in my main project as an external project.
In the external project’s .unoproj file there is:
That’s not the same error as above, though it looks similar, so the fix above might not work for you.
The file uObjC.h comes from a part of our automatically generated iOS library bindings (which are deprecated in favour of foreign code), but the project doesn’t actually reference the package that includes the file. From a quick glance it looks like the include might not actually be necessary and/or can be replaced with uObjC.Foreign.h. If it turns out it’s needed it should work after adding ObjC to the Packages list in the unoproj.
It looks like those files are not written with Foreign Objective-C in mind since you’re getting type errors, so you might have a better time if you set filetype to CSource and CHeader instead of ObjCSource and ObjCHeader in the unoproj. UXL macros are expanded in a way that’s compatible with foreign code if you use ObjCSource/Header, doing some boxing and unboxing of objects automatically. But it looks like this code is written assuming the macro expansion is just the plain expansion that we do for C and C++.