-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide static binaries? #249
Comments
@keith Make sense let me check it and get back to you. |
@keith as far as I understand, the newly introduced We’re looking into whether we should maintain versions of both static and dynamic, and if dropping the dynamic framework wouldn’t work for certain use cases. We’ll get back to you soon. Also, out of the 2 benefits you mentioned, which one is more important? I'm asking since the first one could be achieved by breaking our framework into smaller subspecs. |
Ah right I'm sorry, this is actually irrelevant because CocoaPods has supported this for a while. The GoogleMaps pods for example are pre-compiled static frameworks.
While you would have to have 2 sets of binaries if you wanted to support both, you could maintain a single pod spec using subspecs, which would simplify things a bit.
Unless anyone is doing something crazy, there shouldn't be a difference to consumers. The only thing you might have to change is your resource loading
We're interested in this for some more reasons that just those I mentioned. Currently Instabug is our only dependency that isn't static, so we're trying to unify that to simplify our build tooling. |
A dynamic framework ( |
We were not aware of that. That will definitely make things easier. Thanks @keith and @kastiglione! We will continue discussing this internally and get back to you soon. |
Another benefit I just realized to providing a precompiled static framework, is you could remove this script referenced in your readme since this would be handled automatically by the linking process. |
We’ve decided to switch to a static framework. We’ll be working on it this week, so it should be available in either the next release or the one after. Will let you know once it’s released. @kastiglione I couldn’t find much that talks about transforming a static binary into a dynamic one. If you have any resources that talk about this, I’d really appreciate if you share them. |
Awesome! Thanks!
…--
Keith Smiley
On May 20, 2018, at 04:07, Hesham Abd-Elmegid ***@***.***> wrote:
We’ve decided to switch to a static framework. We’ll be working on it this week, so it should be available in either the next release or the one after. Will let you know once it’s released.
@kastiglione I couldn’t find much that talks about transforming a static binary into a dynamic one. If you have any resources that talk about this, I’d really appreciate if you share them.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@HeshamMegid I don't know if there are resources that talk about it. Here's an overview. The two main kinds of binary files in this discussion are:
Source files are compiled into intermediate build files, and those intermediates are in turn linked into binaries that can be loaded and run. Dynamic frameworks (and executables) can be produced from any combination of
These three targets could be structured with the majority of the source files as part of the static library. The application and framework would in turn link in the static library via Xcode's "Linked Frameworks and Libraries" section. In this example, Xcode would build a static library, and then use that to produce the app and the framework. To do all this linking, Xcode isn't doing anything fancy, it calls commands in the toolchain. At its most basic, converting a static library to a framework would look like this:
Typically build systems don't use
I've reduced this a bunch to focus on what would be relevant for the discussion. The flags above are the most noteworthy (but not necessarily required). Despite the use of Hopefully this helps some, I'm happy to answer more questions. To support both static and dynamic, you probably have two primary options: 1. Use the Xcode structure I mentioned above: a static library target and a framework target, where the framework has no code and simply links in the entirety of the static library, or alternatively 2. Release binaries that contain just static frameworks, but also provide scripts that generate a dynamic framework on the developer's machine. |
@kastiglione thank you so much for taking the time to write this up! We'll give it a try as soon as we change our build scripts to produce a static framework. |
@keith I face some problems with cocoapods and static library I hope that you can help me to fix it |
@Kmohamed heads up that Keith may not be able to reply until early next week. |
@kastiglione Thanks |
@Kmohamed can you elaborate on the structure you're trying to make work? |
@keith As you know we split Instabug into two frameworks (Instabug and InstabugCore) |
So you're vendoring InstabugCore as a development pod and as a precompiled static framework? Or you have a separate internal podspec using the sources? |
Yes, We have a separate internal pod spec using sources |
If I'm following correctly, here's a sample project that shows this layout working. Instabug is the main target which is a static framework, and I'm including InstabugCore with CP |
Thanks a lot 🙏 🙏🙏 |
I noticed one thing that you'll likely have to handle before shipping static binaries, it looks like both Instabug and InstabugCore have these duplicate symbols:
I assume it will be easy enough for you to either make the static, or reference them from InstabugCore in Instabug, just FYI |
You are right and I already fixed it. Related to static library I would like to apologize for being late in providing a static library from Instabug it takes some time because we need to make some changes in our codebase architecture so in order not block your migration from dynamic frameworks to static libraries here is a quick version from Instabug that you can use and we will include it in our releases very soon. |
Thanks for sending this! 2 quick pieces of feedback:
|
Sure, will do. |
Found another issue, it looks like some of the object files here were built with a minimum deployment target of 11.4, instead of something lower:
|
@keith sorry for that here is the new library |
btw @keith you need to add |
I think this is expected for static frameworks for those including manually. For those including with CocoaPods or something, they won't notice this.
Yep! No problem, we were already using those, it appears to work correctly now! |
Great 🎉 |
Do you plan to make an official release with this soon? |
Do you mean using cocoapods ? |
Or just on your release page |
Yeah sure, |
We haven't integrated this yet (besides my testing) just because it'd be nice to do it through the official release channels |
Next release will include static library on the Github releases. |
Awesome! Sounds great!
…--
Keith Smiley
On Jul 10, 2018, at 09:22, khaled el morabea ***@***.***> wrote:
Next release will include static library on the Github releases.
is it ok for you to be on Github releases ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I succeed to make it thanks 🙏 |
@keith @kastiglione This release contains support for static library |
Thanks!
…--
Keith Smiley
On Jul 30, 2018, at 04:26, khaled el morabea ***@***.***> wrote:
@keith @kastiglione This release contains support for static library
Sorry for being late it require some changes in our code structure and some scripts to automate producing both (dynamic and static).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
FYI, probably not an issue, but it looks like this object file:
Is included in your binary twice. But there aren't actually any symbols provided by it. |
There are also some other files with no symbols:
|
Actually |
Is this a build time error ? |
This isn't an error, I just noticed this in the binary right after download, not related to our project |
Does all Instabug categories have symbols expecpt these files ? |
Looks like there are quite a few others that don't as well. You can see this with |
Thanks a lot i will check it and get back to you |
@keith is this what you mean by there is no symbol ? |
Ah sorry, I was filtering symbols such that undefined and local symbols were hidden. False alarm! |
No worries 😉 |
@Kmohamed looks like #249 (comment) isn't fixed in the new release |
Yes it’s PR didn’t merge yet. I will make sure to release it soon |
Is there any chance that you all could provide static framework versions of Instabug as well as or in place of the dynamic ones? CocoaPods supports this for the past few versions. There are 2 benefits I think we'd see.
Any unused symbols could be removed at link time. Meaning if consumers of the SDK don't end up using the whole thing, they can end up with a smaller binary size increase from integrating Instabug.
This decreases the amount of dynamic linking time when the apps are being launched, which helps the app launch faster.
Thoughts?
The text was updated successfully, but these errors were encountered: