As part of a research project at school, I'm exploring mobile specific energy optimizations and am building infrastructure to test these optimizations on a popular mobile platform. Given my background in LLVM, I have decided to setup the testing infrastructure around the iOS platform. I thought that since Xcode already uses LLVM under the hood, it should be easy to integrate a copy of LLVM compiled from source into the Xcode toolchain, but I haven't been able to find an option to accomplish it in Xcode yet. (I'm new to OSX and haven't worked with Xcode before)
Am I overlooking anything, or is such an integration not supported out of the box in Xcode?
It's for obfuscater-llvm, but it should work for a "normal" llvm:
https://github.com/obfuscator-llvm/obfuscator/wiki/Installation#integration-into-xcode
Related
We are prebuilding some libraries (mainly with carthage) for some of our projects to reduce development times. These libraries are not updated very often, but we want to update our XCode versions pretty fast.
Now every time a new XCode brings a new swift version, we are seeing this incompatibility issue
File.swift:4:8: error: module compiled with Swift 5.3.2 cannot be imported by the Swift 5.4 compiler: /......./Debug-iphoneos/Alamofire.framework/Modules/Alamofire.swiftmodule/arm64-apple-ios.swiftmodule
How can I pre-build my dependencies in a way that a swift update wont affect it and I dont have to re-build the dependencies with every xcode update (I thought thats what ABI stability was for? How can I activate that?)
It sounds like you're misunderstanding what ABI stability enables. The main benefit is that it allows the OS to include only one version of the Swift standard library, and for all Swift binaries to share it. What you want is "module stability". From the docs on ABI stability:
ABI stability is about mixing versions of Swift at run time. What
about compile time? Right now, Swift uses an opaque archive format
called “swiftmodule” to describe the interface of a library, such as a
framework “MagicKit”, rather than manually-written header files.
However, the “swiftmodule” format is also tied to the current version
of the compiler, which means an app developer can’t import MagicKit if
MagicKit was built with a different version of Swift. That is, the app
developer and the library author have to be using the same version of
the compiler.
To remove this restriction, the library author needs a feature
currently being implemented called module stability. This involves
augmenting the opaque format with a textual summary of a module,
similar to what you see in Xcodeʼs “Generated Interface” view, so that
clients can use a module without having to care what compiler it was
built with.
This is not yet supported in any version of Swift.
I'm distributing libraries for other developers to use (http://empiric.al). I've noticed that between swift versions, even 2.0 to 2.1, I'll get Module file was created by a (newer/older) version of the compiler.
I need to be distribute in a future-proof way.
How can I make sure my compiled frameworks can be used by newer versions of Swift in the future so I don't have to recompile as soon as Apple puts a new beta out?
From Apple's website:
Binary Compatibility and Frameworks
While your app’s runtime compatibility is ensured, the Swift language
itself will continue to evolve, and the binary interface will also
change. To be safe, all components of your app should be built with
the same version of Xcode and the Swift compiler to ensure that they
work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
Until the Swift ABI (application binary interface) stabilises (I'm guessing another year or two) the only way to distribute libraries that will work across different Xcode versions is to distribute the source code. Cocoa pods and Carthage are both good tools for making library distribution easier but for Swift code they will still rely on source code being available.
It might be possible to have an Cocoapod that detects the version of Xcode it is run with and then downloads and provides the correct build of your library but you will still need to build the libraries for all Xcode versions that you want to support and recompile every time Apple release a new Xcode but at least the user wouldn't need to download a new version manually.
I'm completely confused and I don't know where to start asking questions. I tried googling, but the terminology is confusing and I'm not sure what either of these things do (except for Xcode). Can someone explain like I'm 5?
I'm on the cocos2d-swift website and after reading the getting started section it says "From this point onwards, using SpriteBuilder is optional.". I don't know what they mean by that.
How do each of these correlate with each other?
Also, how is an API Documentation Browser and Code Snippet Manager useful to an everyday iOS Developer?
cocos2d-swift is a framework that enables you to build things like sprite-based games quickly.
SpriteBuilder is a tool that helps you build your own multilayered sprites (images and animations grouped into a single package -- i.e. Mario, a Goomba, a Fireflower fireball, etc.).
Xcode is a developer environment in which you write your source code, compile, distribute, and test.
CocoaPods is a tool that fetches and manages framework/SDK dependancies.
You would use CocoaPods to fetch the cocos2d-swift framework so that you could build a sprite-based game in Xcode using sprites you generated in SpriteBuilder.
Not sure what Cocos2d is, but swift is the latest programming language by Apple for both OS X and iOS development.
http://en.wikipedia.org/wiki/Swift_(programming_language)
SpriteBuilder is a framework used to create games for iOS very quick. Think of it as a game engine.
http://www.spritebuilder.com/about
Xcode is the IDE (integrated development environment) that you use when writing native OS X and iOS applications. It's awesome!
CocoaPods is a way to load in third-party libraries and frameworks without having to manually install them on your own. It also makes it very easy to keep the frameworks up-to-date. Pods also allows your project to be more portable as it's much easier to install an application with multiple dependancies via Pods.
http://cocoapods.org
A documentation browser is good if you want to have access to documentation while offline. However, I almost always use Google to find what I'm looking for regardless of what technology I'm working on. Google is just the best way to search.
Finally, I'd start off with this book. I read the first edition years ago, and made things very easy for me to understand.
http://www.bignerdranch.com/we-write/ios-programming.html
Hope this helps!
Here are some basics:
XCode (A Program)- Most of your iOS development will happen here. Coding, creating the app etc.
Think of an SDK as a suite of commands or tools you can use-API's (API - Application programming interface)
Cocoas2d (An SDK) - Game engine. A software development kit for creating games. you would pull this library of code and tools into xcode to use it.
SpriteBuilder (An SDK) - Suite of tools for building games. Just like Cocoas, you would pull this into xCode to make use of it as you code.
CocoaPods - A tool for linking/loading SDK's into XCode and easily updating them.
Moral of the story: XCode is the software you will use for everything. Everything else are just additional libraries of code you can pull in.
Looking at the cross-platform nature of potrace http://potrace.sourceforge.net/, is it possible to compile this for iOS? If so, how?
Yes, it is possible to compile potrace for iOS.
As a matter of fact, most open source libraries using standard (GNU) configure tools that compile on MacOS X will easily compile on iOS, because they are likely free of platform-specific code (e.g. linuxisms) and standard configure tools allow cross-compilation.
You can compile these libraries in the shell by pointing configure to the proper toolchain and SDKs. Paths changed with Mavericks and Xcode 5, but fortunately automated scripts exist for more popular libraries such as expat.
The proposed solution is based on the x2on/expat-ios project on GitHub. Their script fixes expat's config.sub which doesn't know about arm64 target. Do does potrace 1.11's config.sub. However, a simpler approach consists in downloading a more recent version of config.sub. Unlike expat, potrace doesn't seem to need any patch to compile for iOS.
Full script build-potrace.sh is available here:
https://gist.github.com/pguyot/dce18af64a71b93c0204
Please note that potrace is licensed under the GPLv2. You might want to check Is it legal to publish iOS apps under the GNU GPLv3 open-source license? question.
The Boost Graph Library is a header-only library and does not need to be built to be used.
it contains some pre-made functions that I want for my iOS application:
dijkstra_shortest_paths
astar_search
However, Boost is not officially supported on iOS (or Android) due to lack of regression testing, and I'm not experienced enough with either Boost or iOS to be comfortable testing it.
Is anyone using Boost.Graph on iOS, and if so is it stable?
Yes, most definitely it's stable.
Apple's LLVM compiler (which is what you should be using for iOS apps) is one of the most C++11 compliant compilers available today, and as such can compile and run boost with absolutely no issues.
Not to mention the fact that iOS is also fully POSIX compliant, which makes most frameworks out there viable for use on iOS. When in doubt, try it and then if it doesn't work, come back and ask a question.
Leverage what is already there, and use it well!
As such boost libraries are stable, but Boost Graph libraries are failing on all darwin flavours (darwin- 4.4_0x intel- darwin- 12.0 intel- darwin- 11.1 darwin- 4.4)
http://www.boost.org/development/tests/release/developer/summary.html
May be you can try other alternatives, like LEDA (http://www.algorithmic-solutions.com/news/archive.htm)
Thanks.