Make project framework/.a smaller

[bamse16]

Hello,

Although not necessary a MapboxGL specific issue, is there a way to split the libMapboxGL.a file in four smaller files?

When trying to commit a project containing MapboxGL to GitHub I get the following error:

remote: error: File Pods/MapboxGL/libMapboxGL.a is 313.22 MB; this exceeds GitHub's file size limit of 100.00 MB

Thank you,
Marius

[incanus]

The builds include debugging symbols for both device and simulator (since the library is open source) that allow you to symbolicate crash logs for your apps. They should get stripped out of the resulting application and into your archive's .dSYM. You could do this ahead of time by changing the settings in GYP.

[bamse16]

Hi Justin,

I forgot to mention that I was installing libMapboxGL from Cocoapods. I don't know if there is a way to change those settings in Cocoapods.

Thank you,
Marius

[friedbunny]

If you're using Cocoapods, the way forward is typically to exclude the downloaded libraries and ask repo cloners to pod install themselves.

[bamse16]

I'm afraid that this is the only solution :(. Unfortunate, because it's way easier to just clone the repo instead of having others to also do a 'post clone/pull' step. This step will have to be ran each time you get a fresh copy from the repo too.

I am aware that there is no easy solution for this, and the easiest of them is to keep your assets below the 100M limit. GitHub could increase the limit (but how much?).

[jfirebaugh]

Yes, a pod install step is definitely the way to go. It's very common for repositories to require an install step, be it pod install, npm install, bundle install, or similar. Conversely, checking large binaries into git is usually a bad idea -- git was designed for source files, and doesn't perform well with large files. There are good reasons GitHub has the file size limits it does, so we aren't going to try to work around them.

[incanus]

I would say that it's not the majority case for iOS developers to use pod install (or CocoaPods at all) so it is definitely a use case to check a library into the source tree in certain cases. However, like @jfirebaugh says, we can't do much about GitHub's limits here. I would recommend a reference or checksum or similar to a remotely-hosted library binary if you are not using CocoaPods.

[ekis]

I am aware that there is no easy solution for this, and the easiest of them is to keep your assets
below the 100M limit. GitHub could increase the limit (but how much?).

As a somewhat orthogonal remark, I really don't think there should be a limit.

I ran into a similar issue migrating a codebase containing large files from BitBucket to GitHub and was surprised with the 100M limit. Also, I do not know if there are any additional limitations but I push 16 G sized branches easily to BitBucket and I am just not sure what's going to happen when I try the same with GH. Entire repo is probably > 150 G in size (with all branches taken into account).

[friedbunny]

Git Large File Storage is a thing that is coming to Github, though there's no mention of what the per-file limit will be.

[ekis]

I've seen it and it's probably still in beta. In addition:

Every user and organization on GitHub.com with Git LFS enabled will begin with 1 GB of free file
storage and a monthly bandwidth quota of 1 GB. If your workflow requires higher quotas, you can
easily purchase more storage and bandwidth for your account.

This is indeed unfortunate - BitBucket doesn't charge for private repositories, allows (seemingly) limitless repo size and has no limits on monthly traffic (at least none that I could see and I've done some crazy pushes).

EDIT: I have just discovered BitBucket has limits for repository size: 2 GB is the hard-limit size. However, despite having huge repositories pushed to BitBucket (as said in above post), I have never had any issues. I don't know if Git is internally that efficient at packing or BitBucket applies some additional data compression but I never even got a warning for crossing 1 GB, let alone 2 GB. Needless to say, there was no issues pushing 100+ MB files as well.

Which I think really makes the case for pointlessness of existing GitHub limitations, even accounting for discrepancy on user base size (I assume GitHub is considerably larger than BitBucket).

[incanus]

We did this over in #1650, so the default distribution is no stripped of symbols and is 20MB to download.