You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As dynamic frameworks are now supported across all platforms and issues are popping up in every other Xcode version regarding modular framework inclusion @phatblat had the idea to wrap libgit2 in a dynamic framework.
This issue is to discuss is as Twitter is not the right place to include everyone.
I started work on this a while ago, keeping some notes in phatblat/pull/1 and overall the experiment was successful. I had a secondary goal of enabling Bitcode #529, but gave up as that is too much work with our current libssh2 and OpenSSL dependencies. Perhaps once libssh2 drops OpenSSL as a dependency.
I will start on some cleanup and move this into a branch here on the main repo where everyone can see and edit. I'd like to collapse the separate https://github.com/phatblat/git2 Xcode project into this one because it's not very big and that will make for less moving parts.
Maybe something like gyp can help generating Xcode projects for the source this way we can just use libgit2 as a submodule and generate the Xcode project from the source each time? We did something like that in MX3 not sure if it supports dynamic frameworks though.
Interesting. I haven't seen a tool like gyp before. Looks like the manual work is in creating the .gyp file which would then be used to generate the Xcode project. Are there any tools to generate a .gyp file from a Makefile?
I'm not too concerned about maintaining an Xcode project for libgit2 as its contents are very likely to be understood by contributors to this project. I'm more concerned about maintaining a parallel build system for our other dependencies, but that's outside the scope of this PR.
I've got a working project which is in a separate repo: https://github.com/phatblat/git2. I created it separate from ObjectiveGit thinking both it and SwiftGit2 could consume it. Since SwiftGit2 has stalled, it would be simpler if the project were here in the same repo as ObjectiveGit. Open to other opinions.
What the framework target should do is just take the source files and compile them into a dynamic framework right? Gyp takes all the files in a directory, takes the files from the include directory and makes a project out of it. Not sure if it supports framework targets yet so have to find out but maintaining a directory is easier than maintaining an Xcode project.
yep. There a little bit more to it. The git2.modulemap and the git2.h umbrella headers need to include all the appropriate files (and not the ones for other platforms like windows and amiga). These could be static as they are in my example repo, but it would be ideal if they could be generated from the cmake build. They would only break if the files in the libgit2 build changed, so probably not a big deal to manage by hand.
Ha, I somehow completely missed @tiennou comment. The thing with cmake is that it still generates a static library with the Xcode project rather than a dynamic framework. As I have 0 knowledge about cmake I have no idea on how to do that either.
I tried with the framework project but it has the same issue, the only thing I could come up with is fixing the root cause in libgit2/libgit2#3636 and not include the header in the first place. Git2Go now happily compiles under Xcode 7.3.
Activity
phatblat commentedon Jan 29, 2016
I started work on this a while ago, keeping some notes in phatblat/pull/1 and overall the experiment was successful. I had a secondary goal of enabling Bitcode #529, but gave up as that is too much work with our current libssh2 and OpenSSL dependencies. Perhaps once libssh2 drops OpenSSL as a dependency.
I will start on some cleanup and move this into a branch here on the main repo where everyone can see and edit. I'd like to collapse the separate https://github.com/phatblat/git2 Xcode project into this one because it's not very big and that will make for less moving parts.
[-]Wrap libtgit2 in a framework[/-][+]Wrap libgit2 in a framework[/+]pietbrauer commentedon Jan 29, 2016
I have a OpenSSL framework laying around if that is of any help? https://github.com/nerdishbynature/OpenSSL
phatblat commentedon Jan 29, 2016
❤️
pietbrauer commentedon Feb 1, 2016
Maybe something like gyp can help generating Xcode projects for the source this way we can just use libgit2 as a submodule and generate the Xcode project from the source each time? We did something like that in MX3 not sure if it supports dynamic frameworks though.
phatblat commentedon Feb 1, 2016
Interesting. I haven't seen a tool like gyp before. Looks like the manual work is in creating the
.gypfile which would then be used to generate the Xcode project. Are there any tools to generate a.gypfile from a Makefile?I'm not too concerned about maintaining an Xcode project for libgit2 as its contents are very likely to be understood by contributors to this project. I'm more concerned about maintaining a parallel build system for our other dependencies, but that's outside the scope of this PR.
pietbrauer commentedon Feb 1, 2016
I don't know about the Makefile but it seems more maintainable than an own Xcode project.
pietbrauer commentedon Feb 1, 2016
I can try and get something working with libgit2.
phatblat commentedon Feb 1, 2016
I've got a working project which is in a separate repo: https://github.com/phatblat/git2. I created it separate from ObjectiveGit thinking both it and SwiftGit2 could consume it. Since SwiftGit2 has stalled, it would be simpler if the project were here in the same repo as ObjectiveGit. Open to other opinions.
phatblat commentedon Feb 1, 2016
It would be good to know if gym would make the project maintenance easier.
pietbrauer commentedon Feb 1, 2016
Yep using that, just with gyp so we can keep the submodules?
phatblat commentedon Feb 1, 2016
Do you mean keep git2 as a submodule?
pietbrauer commentedon Feb 1, 2016
What the framework target should do is just take the source files and compile them into a dynamic framework right? Gyp takes all the files in a directory, takes the files from the include directory and makes a project out of it. Not sure if it supports framework targets yet so have to find out but maintaining a directory is easier than maintaining an Xcode project.
phatblat commentedon Feb 1, 2016
yep. There a little bit more to it. The git2.modulemap and the git2.h umbrella headers need to include all the appropriate files (and not the ones for other platforms like windows and amiga). These could be static as they are in my example repo, but it would be ideal if they could be generated from the cmake build. They would only break if the files in the libgit2 build changed, so probably not a big deal to manage by hand.
tiennou commentedon Feb 1, 2016
I might obviously be missing the whole picture, but IIRC CMake supports generating Xcode projects already ?
pietbrauer commentedon Feb 23, 2016
Ha, I somehow completely missed @tiennou comment. The thing with
cmakeis that it still generates a static library with the Xcode project rather than a dynamic framework. As I have 0 knowledge aboutcmakeI have no idea on how to do that either.pietbrauer commentedon Feb 25, 2016
I tried with the framework project but it has the same issue, the only thing I could come up with is fixing the root cause in libgit2/libgit2#3636 and not include the header in the first place. Git2Go now happily compiles under Xcode 7.3.