Integrating React-Native and TesseractOCR - xcode

I am attempting to integrate the TesseractOCRiOS package as part of the implementation of the react-native-text-detector package (https://github.com/zsajjad/react-native-text-detector). However, I am unable to compile under iOS, it fails with a 'TesseractOCR/TesseractOCR.h' file not found error.
I can see TesseractOCR in my Pods directory in Xcode but it does not follow the normal packaging convention. By this I mean, normally, I see a *.framework package within the directory but not in this case. I see the TesseractOCRiOS/TesseractOCR directory and within there, the *.h header files, *.m implementation files and lib/include directories.
I tried attempting to reference the header files through the Build Settings/Header Search Paths but that did not work. Thoughts on what you need to do in XCode to find the necessary header files?

Related

PlatformIO cant find included libraries

I am running into a strange issue with including libraries in the lib folder.
Project details:
ESP32 with Arduino Framework
Trying to get the Adafruit HX8357D LCD to work
What I have done:
Please see the picture attached. I have included all the libraries that I should need. When I compile I run into the "No such file or directory error. I have clearly included the "Adafruit_I2CDevice.h" file in the lib folder under its master folder. But the compiler does not see it. Why?
If I move all the .h and .cpp files in the Adafruit_BusIO-master folder to Adafruit_GFC-Librari-master folder then the "fatal error: Adafruit_I2CDevice.h no such..." error just changes to a different file that is located in the lib folder.
This means there is a deeper issue here with the linker.
Does anyone know why it is doing this? I have not in the past had issues with including files located in the lib folder into various other sources.
Any help would be great.
Thank you
I use TFT_eSPI by Bodmer for Adafruit HX8357D. I use the following command to install the lib in my project and it does all th taff.
pio lib install "bodmer/TFT_eSPI#^2.3.64"
In your case have a look to c_cpp_properties.json in .vscode of your projet to be sure that the "includePath" and "path" points to the good include directories.
From the home screen of PlatformIO, you will have to go to the libraries section and search for your desired libraries there, assigning libraries to your desired libraries from there. Only then it will work properly.
If your libraries are successfully added, they should be inside the .pio\libdeps of your project directory.

Building a React Native bridge but a file within the framework can't be found

I'm trying to build a React Native wrapper for the RichRelevance iOS SDK.
I've created the wrapper project and imported it into my React Native app. I'm using Cocoapods to add the RichRelevance SDK to the app
I'm now attempting to import the RichRelevance SDK into the wrapper project using:
#import <RichRelevanceSDK/RichRelevanceSDK.h>
The problem I have is that when the compiler attempts to compile the RichRelevanceSDK, it throws an error that one of the files is not found:
Line 63 is the original import that was written in the SDK. I added Line 62 to show that the file can be found if the type of import is changed. However, this isn't really an option since I don't want to modify the SDK (I don't own it).
In either type of import, I'm able to cmd+click the file and go to the definition. So XCode seems to know about the file. Additionally, I see the file in the Project browser under:
Pods -> Pods -> RichRelevanceSDK -> RCHImportable.h
The primary difference with this file is that, if I look in the file browser, that file is located in a sub-folder, relative to all of the other files in the SDK:
I'm hoping there's a way to change my wrapper project so that this file can be found, so I don't have to edit or fork the SDK files.
So far, I've attempted to update the various Search Paths in my wrapper project but with no luck. I've added the following two paths to all of the Search Paths:
UPDATE:
I was able to make some progress and I can now get it to compile.
I ended up:
cloning the SDK's repo to my computer
removing the SDK from the Podfile
adding the SDK's xcodeproj file to MyApp/Libraries
adding the SDK.framework file to MyApp -> Embedded Binaries
I can now import the SDK into my bridge module
I would still prefer to find a better way to do this though. This method either involves me committing the SDK to our repo or asking all of my colleagues to clone the repo to their machine. NPM can't seem to install the repo; my guess is this is due to the repo missing a package.json file
There does appear to be something wrong with the packaging, as the header in question would appear to be captured in the public_header_files glob in the Podspec.
However, I think more direct path is to simply include the RCHSDK.h file, as RCHSDK is the entrypoint to the SDK functions. The RichRelevanceSDK.h serves primarily as a shorthand for importing additional headers versus specifying them individually.
Alternatively, you can follow the instructions in Include of non-modular header inside framework module, this seemed to correct the issue in local tests.

cmake-gui show blank except source code directory and binaries directory

After installing cmake-3.8.1-win64-x64 I got thisenter image description here
So what can I do with this? Thanks.
cmake-gui does not help you create cmake configuration files, it parses these files to generate and configure projects.
In your source code directory, you should have a CMakeLists.txt file which defines the rules for CMAKE to configure your problem. That directory should be entered into the first box.
Next, you get to decide where to build the binaries. We could do it in the source directory, but the generated artifacts could pollute what is already there. "Cleaning" the build by deleting all of those artifacts while keeping the original sources is tedious at best, so it's a good idea to make an empty directory and use that as your binaries path.
Once you have those fields entered, you should be able to "Generate" or "Configure" your project. If you need help creating a CMakeLists.txt file (that's really the complicated part), then check out their tutorial.

Linking Mac Frameworks using Premake and GNU Make

I have a "cross platform" application that uses two code repositories at the moment, maintained relatively independently, and built with VS / Xcode depending on the target platform (win or mac respectively). I fell in love with Premake after using it on a few previous projects and am trying to pull all of my code for this application together into a single cross-compilable codebase.
I don't want to rely on Xcode, and instead want any developer to be able to build on Mac using either Xcode or gmake. I have a non-standard framework that I want to link to and include in the repository (it won't be located in /Library/Frameworks or any of the default mac framework search paths). I've added the framework file in a directory in my project /lib/TheFramework.framework. My premake file contains the following under the project definition:
includedirs {".", "lib", "lib/TheFramework.framework/Headers"}
libdirs {"lib"}
links {"TheFramework.framework"}
When I compile, (running $ premake5 gmake and then $ make), I get a header file not found error. Is there something wrong with my search paths? Am I missing a path or a flag somewhere?
Thanks!
Before looking at what you need to do with premake, let's first look at what needs to happen under the hood.
When compiling a mac program with a non-standard framework on gcc or clang (which is what your resulting make file does) it is necessary to do two things:
Specify the name of the framework, via -framework TheFramework - This is what premake does when you provide it with links {"TheFramework.framework"
Specify the location of the framework, via -F /Path/To/Framework/ - This is currently not being handled automatically by premake.
I've made a simple test c program that uses the SDL2 framework and compiled it with gcc: https://gist.github.com/JohannesMP/6ff3463482ebbdc82c2e - notice how when I leave off the -F /... flag I get an error that is probably similar to what you described.
So what is happening is, although you are providing premake with the include dir, premake will not add that the proper -F flag.
One way around this is to do the following:
configuration {"macosx", "gmake"}
buildoptions {"-F /Path/To/Framework"}
linkoptions {"-F /Path/To/Framework"}
(See here for an example project: https://gist.github.com/JohannesMP/9a9b5263c127103f1861#file-premake5-lua-L24-L26 )
In premake5 this will blindly append the code provided to both the build step as well as the link step. It is necessary to do it both for build as well as link.
Just keep in mind that, because premake doesn't process or check the build/link options for being valid, a user will receive an error if the provided path doesn't exist on their machine. For example while you might have a framework in your user-specific directory ~/Library/Frameworks, since that folder doesn't exist by default another user might be using the global /Library/Frameworks instead, and when they try to compile your premake project with gmake they will get a warning:
ld: warning: directory not found for option '-F/Users/<NAME>/Library/Frameworks'
At this point, it seems that there is no 'safe' way to get premake5 to try to include the framework path, but that may change in the future.
Check out this issue I posted on the premake repo: https://github.com/premake/premake-core/issues/196

Deploying cocoa application and its C++ dylib how to pack them?

I am new to cocoa and mac development. I have written an application which is combination of objective-c using cocoa framework and backend written in C++ library dylib.
I am using xcode 4.6 and have the above two projects Cocoa app and my C++ library. C++ is also my own project.
Now it is time for deployment. I want to make a pkg installer for it.
I could run/debug it in the xcode 4.6 because I had added search library path in the object-c project settings to be the output directory of the C++ project. Therefore it could find the dependency and run without crash.
Now in the Objective-C project tree inside the xcode I see products -> mysoftware.app file. if I find the location of this mysoftware.app file in the finder and run it, it crashes. I open the package contents of this app files and I see contentsfollowing structure
contents\(info.plist, MacOS, pkginfo, resources )
I do not see my C++ library in there, when I run mysoftware.app directly double clicking it crashes as it can not find the dylib I see the stack trace in the report window it can not find dylib, complaning that library not found usr/local/lib/mylib.dylib
I have also manually put the dylib file in the .app within the MacOS where my executable is, hoping that it will find the lib from the same directory, it did not , gave the same message above and looking from the the sane location /usr/local/lib/mylib.dylib
So my question is how do I resolve dependency of .app package for deployment, should I need to put the dylib inside the .app package ? how do I do that and then my next step would be to put this single .app thing in the pkg installer,
Thanks
This is what worked for me:
Drag the dylib into your Frameworks.
Add a Copy Files build phase, destination Frameworks and put the dylib there.
Add a Run Script phase which has the following script:
MYLIBNAME=libmylib.dylib
install_name_tool -change /usr/local/lib/$MYLIBNAME #executable_path/../Frameworks/$MYLIBNAME "$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH"
That's it. The script tells your app to load the dylib from the right place - otherwise it will complain about not finding the dylib at runtime.
Note that you don't need to change anything in the dylib itself - it could be supplied from elsewhere.
I resolved it so I am putting up this answer to help others who want to do the same.
The dylib has to go in one of the sub folders within the application bundle (i.e. mysoftware.app). Could be MacOS, Frameworks or any sub folder we decide to put it in.
The first step is in the target settings of our dylib, we set the install path to be relative to the app bundle (mysoftware.app), so in Xcode target settings of lib I set it to:
#executable_path/../frameworks
You can also use #rpath (You might want to research on that, I think it is more flexible than #executable_path)
Xcode will change the install name as well for our dylib.
Then in the Objective-C project using our dylib in the Project settings -> Build phases -> Link -> we drag our dylib here from the products node of the dylib project.
In the Objective-C/Cocoa project, the last step is to add a build step named copy files, and it should show a combo box telling you the target folder of the bundle. I set it to frameworks (this will depend on that relative path you choose when setting install path of your dylib) . The second part of the 'Copy Files' build step is to provide the souce file to copy. That's our dylib file that we want to pack in the bundle's Frameworks folder. So drag the dylib file from the products (of your dylib project) to the source file of the build step.
And that's it.
Now when we build the Objective-C or Cocoa project, if our build steps and install_path , etc are correctly configured, it should build fine. After a successfull build of the Cocoa project, go to Products -> mysoftware.app -> Locate in the Finder and when you run it, it should run fine. Since the dependency dylib is in the Frameworks folder of the bundle and correctly linked. You can see the package contents of the bundle to see if the Frameworks folder contains your dylib file.
To my surprise, the path where a dylib is stored has to be part of the dylib. So when a project links to this dylib it will copy the same path in itself, so when we run the Cocoa app which was linked to that dylib, it will look for it at exactly the same path which it copied from inside the dylib and we are responsible for telling the dylib where it exists. In the form of install_path, etc.
There are tools to manually update the dylib's install path stored in the Cocoa project using that dylib. If update the path of an existing bundle using these tools it should be changed in the client of the dylib, not required in the dylib itself.
If we've the code then we can change it in Xcode as instructed above.
otool -L my.dylib for example can be used to see the dylib install path of an existing binary lib
install_name_tool -change can be used to update the install path of existing binary lib

Resources