-
Notifications
You must be signed in to change notification settings - Fork 145
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
Break up into separate dylibs #13
Comments
It's feasible ; I had it that way at some point in the history of the project. Even though The two questions I have (and where I need help) are:
|
To answer your questions:
|
You're right, that should work. I'm going to give it a try. @louisdh, as the sole official user of ios_system, would that impact your workflow? Any comments? |
OpenTerm currently does |
It's in the "dynamicLibraries" branch, if people want to test. I'm going to do some more testing before merging with main branch. Pro: easier to compile the big projects (lua, python) who can be (almost) totally independent from iOS_system. |
The change broke |
Aye, it works if I use the mangled name |
I think I can close this one. |
I'd suggest building each command as a dynamic library (either .dylib or .framework), and lazy loading them at runtime.
As noted in the README, all the code for all of the commands is loaded into memory at app launch. This seems wasteful & unnecessary, and probably won't scale too well when adding more commands over time.
Additionally, it looks like they are currently being built into a single Xcode target. It'd be great if each command was its own target, with defined inputs/outputs (i.e. build these source files into this dylib). That way it's easier to pick & choose, and scales better.
The text was updated successfully, but these errors were encountered: