ios support about cdep HOT 9 OPEN

I have very rudimentary support for cdep with ios as a target. I'm still working on getting it cleaned up and ready to submit.

Word of warning, the solution I'm working on depends upon CMake to generate the XCode project. It will generate a framework if there's a shared lib being requested. However, if you have an already existing XCode project, then likely, you'd want to utilize the framework that's generated.

Also note that there's a bug in CMake's XCode generator that prevents the generator from creating a schema and wasn't fixed until 3.9. The version of CMake that Android comes with is 3.6. So, if you want to use the same version of CMake (3.6) that ships with Android Studio, then you'd have to open the XCode generated project (rest can be done through command line). However, I recommend switching to a system CMake so it can be used in both places.

from cdep.

Ah excellent, thanks for the update. We generate our Xcode projects though CMake so your solution should work for us.

I have build some kind of python framwork, on Android, to build various open-source projects with the NDK and I'd love to kill it and use something open-source instead, and CDEP looks like the perfect candidate for that. We still have nothing on iOS yet (still a collection of shell scripts). We build curl, openssl, leveldb, boost, luajit, libpng; but that list is always changing.

from cdep.

from cdep.

• curl (might go away soon)
• openssl (-> BoringSSL ?) / the one thing that looks complicated for BoringSSL is that it requires golang to build. Not sure how CDEP helps with that.
• leveldb (uncertain too, might also go away)
• luajit (need options to turn JIT off, as this is forbidden on iOS).
• libpng
• breakpad (depends on lib curl, but we don't want to bring in curl ...)
• satori sdk
• luadbg (... can't find where this is coming from ...)
• boost (but this is going away soon as a dependency for us, so not too important)

Those packages don't have too many dependencies.

from cdep.

@jomo I'm definitely going to tap you for code review. I'm still going with the design that we discussed way back when we first chatted about it.

The project structure I'm using as a test bed is this: https://github.com/gpx1000/ARKitARCoreBridge There's no cdep in there yet as I'm doing that development on a separate branch (want it working before committing changes to original source). However, the general idea is to enable full iPhone/Android cross platform building in the same manner that this "test bed" does with cmake.

I'm thinking that XCode projects that don't use CMake would be able to use the CMake generated frameworks so we might be able to rightly punt on full XCode support as that could be a documentation thing for most users. Definitely let me know if you guys think there's a different path that would be better. I'm not adverse to having a generator that natively creates/edits XCode Projects; but am not knowledgable enough about the XML spec XCode uses to do it so am leaving it as beyond my scope for now.

Once I hit a version 1 I'll submit the PR and can have a more productive discussion there. For now, the big task is to separate out the two changes I'm working on (this and shared libs so can do one PR for each). Then to write the unit test system for iOS to work with travis... WIP. Probably a month or so away from a real version release (free time only project's are like that).

@bsergean do you have specific need for OpenSSL instead of BoringSSL? I ask because I made a boringssl cdep package that I'm also using as a test package for iOS (so it has Android/iOS libs already).
I'm also adding in firebase support to the example project for the exact reason of getting another package to test with that has support in both OSes.

from cdep.

We don't have any real need for OpenSSL instead of BoringSSL, except that we know that the version of OpenSSL right now is 'legit' / approved by Google. On IOS we only need the libcrypto part of SSL, on Android we need libcrypto + libssl. I don't know if this is something that could be configured with CDEP (2 packages instead of one ?), because we'd like our binaries to be as small as possible.

from cdep.

What a great use case. I didn't consider wanting only one lib out of a package. The iOS version generates a framework project and target definitions for each library as a corollary to creating a framework definition. Thus it should be fairly easy to only grab/install the lib you want on iOS.
i.e. if you want libcrypto to link with you just add it to your link list.

However, Android's version isn't using targets in this manner so you'd wind up with all libs required to satisfy the "boringssl" requirement or you'd want to create your own package that only supports some of the libs. The good news about all this is it's decentralized, so making a new package is a good way to go if you have specific needs that gives you an "in house" version.

from cdep.

@gpx1000 you probably meant to mention @jomof :)

from cdep.

from cdep.