Skip to content
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

Merge iOS changes from Wadjet Eye fork. #278

Closed
monkey0506 opened this issue Sep 22, 2015 · 7 comments
Closed

Merge iOS changes from Wadjet Eye fork. #278

monkey0506 opened this issue Sep 22, 2015 · 7 comments
Labels

Comments

@monkey0506
Copy link
Member

@monkey0506 monkey0506 commented Sep 22, 2015

Janet was kind enough to supply me with the following list of commits which could be cherry-picked back into the main source (her iOS branch is littered with project-specific changes that are not fit for merging). I believe this will require some more delicate review, however, as not all of the changes seem appropriate.

e0a7673 - Possibly a memory leak
c1754b9 - Memory leak in ReadString
144df21 - Sound crash bug fix
46b50dc - Added Allegro library project
57856c6 - Added multi-architecture liballeg.a
11a4077 - Patched and created "dumb" project.
630b383 - Dumb project builds
3b84d21 - Added compiled libdumb to AGS project.
aa498cf - Downloaded Freetype
b02380a - Added cdave1's Freetype project
9793b08 - Ogg downloaded
df663f8 - Added OGG project
47f20b9 - Set up OGG project
ec4a55e - Rearranged Ogg project
bd9569f - Added compiled Ogg library
647a56d - Updated scripts for theora
e53a123 - Updated and patched Theora
4bb7a39 - Theora compiles
d628040 - Added compiled theora library.
6e5498c - Removed MAKE from tremor script
ae7a16c - Updated Tremor from svn
8ec21f6 - Added tremor project
d4a4a96 - Compiled tremor
fa77a54 - Added libaldmb target to dumb project
44eb08d - Plugin system updated to 64-bit
93113f7 - Restore audio after phone call
ac070d3 - Crude hack to restore audio after answering phone call

@ivan-mogilko

This comment has been minimized.

Copy link
Member

@ivan-mogilko ivan-mogilko commented Sep 22, 2015

I could take a look, although it seems to me that most of these changes are applied to xcode project, so I will be not much help there.

Would not it be too difficult for Janet to also explain the purpose of these changes (except obvious ones)?

PS. this cannot be labeled as "pull: wip" - that is a tag we created for pull requests that are under fixing after code review.

@ivan-mogilko ivan-mogilko added res: task and removed pull: wip labels Sep 22, 2015
@JanetGilbert

This comment has been minimized.

Copy link
Contributor

@JanetGilbert JanetGilbert commented Sep 22, 2015

Most of the changes are to add xcode projects for the libraries that ags
needs to be able to compile on iOS. These libraries used to compile
using cmake, but the method was obsolete and no longer worked. The
libraries needed to be recompiled to add a 64-bit slice, because
32-bit-only apps are no longer accepted in the app store.

Janet Gilbert

On 9/22/2015 4:36 AM, Ivan Mogilko wrote:

I could take a look, although it seems to me that most of these
changes are applied to xcode project?

PS. this cannot be labeled as "pull: wip" - that is a tag we created
for pull requests that need to be reworked after code review.


Reply to this email directly or view it on GitHub
#278 (comment).

@rofl0r

This comment has been minimized.

Copy link
Contributor

@rofl0r rofl0r commented Sep 22, 2015

since this is a source code repo, it's a bad idea to add precompiled libraries, especially considering that these are all standard libraries which are usually shipped with all major linux distros. binaries increase the size of a source code repo a lot, and they need to be checked out by everyone, even ppl not interested in them. additionally, they will eventually need to be recompiled and further increase the bloat of the repo since every change is forever saved in the git history.
a smarter approach would be to add another independent project that gathers the prerequisite libraries via a script and compiles them with the users compiler with the right settings for his target platform.
later, the directory containing the libraries and its headers can be passed via the usual mechanisms to ags' makefile infrastructure, for example
make CPPFLAGS+=-I/path/to/headers LDFLAGS+=-L/path/to/libs

@sonneveld

This comment has been minimized.

Copy link
Member

@sonneveld sonneveld commented Sep 22, 2015

I wouldn't mind a little time to test this on my machine and also add a
part time build job on team city. Still away but back next week.
Last time I tried to build these libraries I had a lot of trouble with the
newer xcodes clang compiler. Plus you need third party tools like cmake.
So compromise for pre built lib might be to build via team city and make
avail via other means.
On 22 Sep 2015 2:46 am, "rofl0r" notifications@github.com wrote:

since this is a source code repo, it's a bad idea to add precompiled
libraries, especially considering that these are all standard libraries
which are usually shipped with all major linux distros. binaries increase
the size of a source code repo a lot, and they need to be checked out by
everyone, even ppl not interested in them. additionally, they will
eventually need to be recompiled and further increase the bloat of the repo
since every change is forever saved in the git history.
a smarter approach would be to add another independent project that
gathers the prerequisite libraries via a script and compiles them with the
users compiler with the right settings for his target platform.
later, the directory containing the libraries and its headers can be
passed via the usual mechanisms to ags' makefile infrastructure, for example
make CPPFLAGS+=-I/path/to/headers LDFLAGS+=-L/path/to/libs


Reply to this email directly or view it on GitHub
#278 (comment)
.

@sonneveld

This comment has been minimized.

Copy link
Member

@sonneveld sonneveld commented Oct 11, 2015

Phew, I got the buildlib scripts working against xcode 7.0. (in another branch) so I can finally test @JanetGilbert 's changes.

@JanetGilbert

This comment has been minimized.

Copy link
Contributor

@JanetGilbert JanetGilbert commented Oct 11, 2015

So we don't need the Xcode projects anymore? How did you do it?

Janet

On Oct 11, 2015, at 12:32 AM, Nick Sonneveld notifications@github.com wrote:

Phew, I got the buildlib scripts working against xcode 7.0. (in another branch) so I can finally test @JanetGilbert 's changes.


Reply to this email directly or view it on GitHub.

@sonneveld

This comment has been minimized.

Copy link
Member

@sonneveld sonneveld commented Oct 12, 2015

Too many things had changed by xcode 7 so I dredged up an old copy of osx lion and installed the earliest xcode I could. Once I figured out how to build in that old environment, I was confident enough to fix the issues that came up with 7. Adding the new 64 bits platforms was actually pretty easy. There was some extra tidying up where we ask xcode to give us the paths for the sdks and binaries instead of fixed paths so we don't need to keep updating them.

I still want to tidy it up and test, but current fixes are here https://github.com/sonneveld/agscommunity/commits/ios-project-fixes

@monkey0506 monkey0506 closed this Jun 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.