[gambit-list] Gambit for mobile?
mevins at me.com
Tue Feb 12 14:51:33 EST 2013
On Feb 12, 2013, at 12:20 PM, Marc Feeley wrote:
> On 2013-02-12, at 1:11 PM, mikel evins <mevins at clozure.com> wrote:
>> On Feb 12, 2013, at 12:04 PM, Marc Feeley wrote:
>>> On 2013-02-11, at 4:52 PM, Andrew Pennebaker <andrew.pennebaker at gmail.com> wrote:
>>>> What's the state of Gambit support for mobile app development?
>>>> Can we have tutorials for writing Android, iOS, and Windows Phone apps in Gambit?
>>> I don't know of any tutorial, but there are several existing project you could examine. For example, you could check how the "Gambit REPL" iOS app is implemented (in the contrib/ directory).
>>> There are also the scripts "misc/build-gambit-iOS" and "misc/build-gambit-android" which automate the process of building the Gambit runtime libraries on iOS and android (those scripts even download the latest sources automatically). Also, the file "misc/simple-make-project.tgz" is a useful starting point if you like make for automating the build process (but not specifically for iOS or android).
>>> But the gist of it is actually quite simple. Take all of the .c and .h files from the lib/ and include/ directories and compile them with the -D___LIBRARY and -D___PRIMAL flags. Then, compile you app.c and app_.c (generated using "gsc -link app.scm") and link all of the .o files together. The file "misc/vc2008.bat" is a shell script showing the steps (when using Microsoft Visual C++, but for other C compilers the process is simular). On iOS, android, etc you'll need to write some FFI interface to call out to the mobile device's libraries.
>> In practice, I've found it to be more complicated than this. You're completely right that the gist of it is just that simple, but there are lots of ways for things to go wrong. Each time I update the Gambit sources, or Apple's dev tools, or OSX itself, there's a risk that I'll have to spend time (sometimes a few hours) monkeying with C flags and LD flags in order to get things working again.
>> Maybe that's not true anymore; I wouldn't know at present, because it's been painful enough a few times that it's conditioned me to avoid updating things until I feel I really have to.
> I usually need to poke at the build settings to get things working, but I attribute this to the complexity of the IDE.
I think most of the complexity is attributable to Apple's toolchain, but it's not all the IDE.
As others have observed, you can build without touching the XCode IDE, and I avoid XCode as much as I can, but that doesn't solve all the problems.
> Gambit requires *no* external libraries (except for libc) and its code is compilable by C, C++ and Objective-C compilers without any fancy command-line options. Some command-line options are suggested on some compilers to improve performance, but they are not required to build a basic system.
> It would be interesting to know which build settings you had to use on Xcode.
I wish I could tell you. You can rummage through the Makefiles in my git repo if you like, but some of what's in there is probably superstition. My routine when things break is to strip out all the CFLAGS and LDFLAGS and start adding them back until I get a build that works. Sometimes, if it takes a long time and I lose some of my discipline along the way, I may end up with some flags that aren't actually needed.
There are a few things I can be reasonably confident of. You should use clang, not GCC, to build iOS apps. If you're using Apple's frameworks (and who isn't, when building for iOS?) then you'll need -x objective-c and the correct -isysroot and -syslibroot. You'll also need -framework with whatever Apple frameworks you actually use.
You have to get -arch right for your target. There are a bunch of other flags that you may or may not need, depending on what your app does, and which version of Apple's tools you're using, and what the phase of the moon is.
Also, sometimes you can wind up with everything building, linking, and running fine, until you try to use Apple's debuggers. LLDB especially seems prone to choking on apps linked to Gambit code.
Once you get things to compile and link without complaints, you then need to ensure that you initialize the Gambit runtime correctly, and that you observe all the required invariants of the calling conventions and memory discipline between Gambit and C. Those details are documented, if you look hard enough, but a good tutorial would gather them all in one place, spell them out in excruciating detail, and arrange them in the order a new user is likely to encounter them.
Let's not even bring up certificates and entitlements.
It's kind of a pain to get Gambit working for iOS, but that's mostly not Gambit's fault. It's painful to develop for iOS, period. A group of the GHC maintainers have been trying to solve the same problems for a couple of years now and, while they're making progress, they still have to field a lot of the same kinds of questions, and new releases of Apple's tools cause problems for them, too.
More information about the Gambit-list