Removing .framework from the repo about tesseract-ocr-ios HOT 25 CLOSED

Maybe is not possible, because cocopods wants the framework ready to use.

Il giorno 29/lug/2014, alle ore 09:29, Cyril [email protected] ha scritto:

Never dealt with it, but will take a look soon.
As I imagine, it's possible to compile the binaries from sources usinf cocoapods, isn't it?

from tesseract-ocr-ios.

This says, it is!
http://www.slideee.com/slide/building-static-libraries-for-ios-with-cocoapods.
Let me study it a bit later...

from tesseract-ocr-ios.

Is it still impossible to configure CocoaPods without aggregating Tesseract into framework?

from tesseract-ocr-ios.

I'm curious what would happen if we just removed the framework and instead used the script that creates it (the "Run Script" under "Build Phases" in the "TesseractOCRAggregate" target) as a prepare_command in the podspec: http://guides.cocoapods.org/syntax/podspec.html#prepare_command What do you think?

from tesseract-ocr-ios.

This may work. Could you try it?

from tesseract-ocr-ios.

So far as I know, we do not need to compile the library in prepare_command.
Typically CocoaPods generates a workspace for your use, like it's written here:
http://guides.cocoapods.org/using/using-cocoapods.html

So, everything you need is just deletting the precompiled library binary from the repo and simply add a pregenerated workspace to your own project as a dependency. In such case, all the projects from the pregenerated workspace will be compiled right after you start compilation of your parent project.

And even if we remove the binary from the repo, it will remain in the repo hystory. So anyway it would take a lot of time to download this repo. So a few steps to clean the repo hystory should be considered as well.

from tesseract-ocr-ios.

@ws233, I think I follow, but if you're confident that will work, could you try doing it for us?

As for purging the framework from the repo history, I think that should work okay because we basically just need to purge the Products folder. It shouldn't affect any users trying to use commits from the past, because they can always rebuild the TesseractOCRAggregate target to get the framework back if they need it.

from tesseract-ocr-ios.

@kevincon, Actually I do not use pods in my projects.
I just worry about the huge repo size and long download time. Since, the user have to download all the repo hystory with every library build in it.

from tesseract-ocr-ios.

There is a small schedule for this task:

1. what we should start from is removing leptonica.a and libtesseract.a from the repository.
   They could be easely changed to the pod set up to the git sources.
   To build .a targets we can use building script.
2. remove iOS bianry framework from the sources. Instead again we should adjust pod specs in such way, that the workspace should be properly adjusted. Instead of adding prebuilded library we will be able to add a workspace, which will be inserted into 3rd party projects and be build as a dependency of the 3rd party projects.
3. Purging large binary files (all of those from previous two steps) from the git hystory, like it's explained here:
   https://help.github.com/articles/remove-sensitive-data/

Finally, that will allow us to significantly decrease the size of the repo with well orderring repo structure.
Actually, the rule for the repo is to have links to subprojects and libraries instead of their binary codes.

What do you think? Is it a good idea to divide this task into 3 small subtasks?

from tesseract-ocr-ios.

Also during purging we should take care about all the tags from the repo, cause they lead for some undeleted files, like it's written here:
http://stackoverflow.com/questions/6920585/how-can-i-reduce-the-actual-size-of-my-github-repo-rather-than-just-my-local-c

from tesseract-ocr-ios.

I agree with last two subtasks but not with the first. Building leptonica.a and libtesseract.a will take a lot of time and may not be so easy for people who using Pods. But this files updating very rarely and not increasing repository weight so much.

from tesseract-ocr-ios.

And as you told, the repository for leptonica and original tesseract are also be updated very rarely, which means that people have to build them very very rare.
And if there is a build script they don't face any issues. Script will do everything automatically.

Again, that's a big violation to store binaries in the repo.

from tesseract-ocr-ios.

If you can configure podspec to allow build that libraries automaticly once after installing pods or on first build - that would be nice. In other way we should leave this libraries in repository(IMHO). Any way there is a lot of work with podspcec. Who dare to work with this issue?

from tesseract-ocr-ios.

@bamx, when you say "build the libraries automatically once after installing pods", I'm pretty sure the CocoaPods prepare_command (see my post above) will let us do that.

Other than that, @ws233, I still believe that if you know how to do this then you should be the one to do it, because I don't understand how exactly to do the step 2 subtask you described above. I'm happy to help with step 3, though.

Also, I agree with @bamx about step 1. We should leave those .a libs in the repo because they very rarely will change. I'm not even sure the Tesseract guys at Google have any plans to do another release anytime soon (beyond 3.03-rc1).

@ws233, maybe you're talking about a way the CocoaPod could build the .a libs upon pod install; if that's so, then please give it a shot.

I don't think I'm going to spend anymore time thinking about this issue because it's not as critical to me as fixing bugs and helping people understand how to use the library to do what they want.

from tesseract-ocr-ios.

So, I switched to the step 2.
I'll share everything I could find on the issue soon.

from tesseract-ocr-ios.

So, that's what I could find and my plans so far.

From iOS 8 and xCode 6 there is a Framework target available.
It does from the box everything we did manually in the Aggregate target.
So, I'm going to remove our 2 targets (TesseractOCR and TesseractOCRAggregate) and add a new one, which is going to be a complete iOS 8 framework in only one target.
That adds some new restrictions, like the deployment target is iOS 8 only. But so far the library do not support iOS 6 as well, so we already lost a lot of very old devices, which cannot be updated to iOS 7 or older. Also, those devices has a very bad camera, which is not enough for tes recognition, so it's ok. We will loose the device with iOS 7, which have not been updated still. But those devices are very few. So it's ok IMHO too.

In such case the Tesseract-iOS framework installation process is as simple as following:

1. User adds our framework as a pod
2. Moves the framework project into his own workspace.
3. Adds our framework as a dependency to all of his own projects.
   That's all. After he or she presses compile button for his own project, our framework will be compiled automatically as a dependency.
   And even 2 and 3 can be done by the pod automatically, cann't they? I'm not sure about it so far, cause I do not have enough expirience with pods.

Advantage: no framework binaries in the repository.
Disadvantage: minimum deployment target is iOS 8 only.

So, if nobody minds about iOS 8 deployment target, I'll continue with it.

from tesseract-ocr-ios.

I'm fine with the iOS 8 deployment target for the reasons you mentioned, but I don't think this is worth doing if the user has to do steps 2 and 3 manually. If CocoaPods can do that automatically, then I think it's a winner.

from tesseract-ocr-ios.

ok. so I'm going on with this.

from tesseract-ocr-ios.

@kevincon, can you try this PR #120.
I haven't try steps 2 and 3, if they automated or not, yet.
But with these steps made manually, everything seems to work OK in my project and the test example project from the framework.

will try to make steps 2 and 3 to run automatically soon.

from tesseract-ocr-ios.

Not sure that deprecating iOS 7.0 is a good idea.

from tesseract-ocr-ios.

Sorry ^.^

from tesseract-ocr-ios.

There is a few posts about the availability of the frameworks on an iOS 7.
http://stackoverflow.com/questions/25909870/xcode-6-and-embedded-frameworks-only-supported-in-ios8

from tesseract-ocr-ios.

I tried this and can confirm, that the framework can be run on a iOS 7.1 in the simulator.

from tesseract-ocr-ios.

I can upload changes after the test it(@"Should draw blocks on image", ...) become fixed to pass on iOS7.1. So far it fails on iOS7.1.
@bamx, could you take a look on it and fix?

from tesseract-ocr-ios.

There is one more advantage of using dynamic framework instead of the static library. :)
Dynamic framework could be released on memory warnings automatically by the system. I'm not sure about it, but it seems very likely. In such case an app can free 5,3MB when it doesn't use tesseract.

from tesseract-ocr-ios.