Hi Phillippe, after reading the last posts it becomes clear, that I know far too less to be a big help here. Since I still find it very interesting I'll try to learn more about gcc and what you did so far. Bad news is that I even did not manage to checkout the code (svn says something like 'can not connect to server'). Maybe it's just unavailable at the moment, i'll retry later. I browsed the svn online but didn't find your modifications.
How can I start? Does it all work as a cross compiler, i.e. can i produce android binaries on my mac? What else do I need an need to know? I think it's obvious, that there is some money in this (think about 100.000 to be potentially available on android platform at one go!) only question is, how to get it out. The donation model used by others like cocos2D seems easy to handle to me, but does not guarantee, that everybody who should would really pay. Yes, Google could be interested (and I actually asked myself why the didn't started something like this on their own...) and a little bird told me they've some money in the bank. So I wish you all the best to get something out of your work. - Kai On 19 Jan., 17:05, Philippe Hausler <[email protected]> wrote: > Well just as a forewarning: this is just the compiler and NOT the > Foundation/UIKit frameworks. So any project that you may want to test out > will need the root classes re-compiled for Android. > > Now this goes back to my original post: How can the applications be > dynamically linked to a library containing those aforementioned classes from > Foundation/UIKit? > The current approach for dynamic linking involves some tricks with dlopen to > a packaged app. e.g. the application is bundled into a JNI wrapper, that > wrapper has a stub for loading the appropriate shared object libraries and > then calls the "main" function from the compiled app. My current loading > tactic loads from another "application" wrapper in this case > /data/data/com.versv.Foundation/libs/libFoundation.so. Which this works, but > it would then require any application compiled to require a "library app" to > provide the libraries required for the Foundation and UIKit objects and calls. > > Is this the best way of approaching shared libraries from multiple > applications? > Even if the UIKit and Foundation libs approach 1-2 mb would they be > reasonable as static libs? > Would my fellow developers think that the capability to utilize this compiler > with a stub application wrapper and framework loaders be worth something > monetarily? If so how much would be reasonable? Just as a roadmap of what I > am thinking of is support for almost all of the frameworks as > re-implementations from the iPhone API all the way from Foundation and UIKit > to CoreData, CoreLocation, GameKit, and the such. > > I 100% think that the compiler alone would be a great addition to the open > source community but my funny habit of needing to eat and wanting to live in > a house/pay bills etc urge me to put the working parts of the direct-code > portability as something for sale. I am open to suggestions for ways of > reaping some benefits other than my own personal ease of use to port apps > across from iPhone to Android. (hint hint maybe someone at google might be > interested in this part of the project) > > Back to the compiler issues. Now since I have a direct opportunity to modify > anything inside of the compiler (especially when it comes to ObjC) what other > features should I try to add in (@namespace, @operator for obj-c++)? Or is > ObjC 2.0 + Blocks + foreach enough to work on? > > Updates on tested features: > Properties: > @property seems to work just fine > nonatomic and atomic > assign, copy, retain work from what I can see (granted that requires > a NSCopying protocol for copying) > I have not yet been able to test any getter/setters > > @synthesize works of what I can tell > @dynamic has not been tested (but should work since @synthesize does) > > Classes > @private works for ivars > direct ivar access has not been tested (but it should work since its fairly > similar to properties code wise in the compiler) > > Protocols > libobjc needs some overhauling to support protocols better (as a matter of > fact i need to re-do libobjc to update to more apple-esque versions) > the initial protocol concept works, however there is no identifier for class > conformance to a given protocol (properly atleast) > > Blocks: > Blocks have not been tested in c, c++, objc, or obj-c++ (not even sure they > compile right yet) > > Fast enumeration (foreach/for-in): > Not yet tested at all (also not sure if they compile yet) > > On Jan 19, 2010, at 9:05 AM, Ben Gotow wrote: > > > > > Hey Philippe, > > > Thanks for posting the project! I think there's quite a bit of > > interest in this, and I'll do my best to help you debug and test the > > compiler. I'll try to use this with some of the code I've written in > > my iPhone app and let you know if I encounter any problems or bugs. > > > - Ben > > > On Jan 18, 12:34 pm, Philippe Hausler <[email protected]> wrote: > >> Well I have not only objc 1.0 support working, but also objc 2.0! > >> In response to the project license type (since it is a modification > >> of gcc it ought to be): it is GNU GPLv2. > >> The project is hosted onhttp://code.google.com/p/android-gcc-objc2-0/ > > >> Support? Well I need to have people test this extensively. > > >> Some things that need to be tested (and probably debugged/worked on): > >> Fast enumeration ala foreach type code > >> Blocks > >> atomic, copy and retain properties (nonatomic and assign work so far) > > >> Right now my major focus is on making the compiler work correctly. > > >> On Jan 18, 4:24 am, kai <[email protected]> wrote: > > >>> Hi Phillippe, > >>> great plan (I discussed this with my colleagues before, then searched > >>> at google > >>> if somebody's already doing this and found this thread). > >>> How is it going? Do you plan anything to make this project public in a > >>> way that I can > >>> support you somehow? > > >>> - Kai > > >>> On Jan 7, 7:11 am, Ben Gotow <[email protected]> wrote: > > >>>> Hi Phillippe, > > >>>> Wait... you've coerced GCC into building objective-C for Android, as > >>>> well as libobjc.a? That's fantastic! Have you tried to compile > >>>> anything against GNUStep's implementation of Foundation? It's pretty > >>>> much identical to Apple's, and it might allow Foundation-referencing > >>>> Objective-C libraries to be linked into Android apps. > > >>>> I realize you have much greater expectations for this project, but > >>>> that alone would be a major accomplishment. I've written several apps > >>>> for iPhone and I'm looking to port one of them to Android. I'd like to > >>>> avoid translating tons of code from Objective-C to Java, and being > >>>> able to keep a single copy of the Objective-C source and compile it > >>>> into a static library for Android devices... that would just be > >>>> incredible. > > >>>> If there's anything I can do to help you in your efforts, just let me > >>>> know. I think you could post this as open source donation-ware and > >>>> make quite a bit. Being able to compile Objective-C static libraries > >>>> for Android (even without UIKit) would save me weeks of work. > > >>>> - Ben Gotowhttp://www.gotow.net/ > > >>>> On Jan 5, 3:48 pm, Gergely Kis <[email protected]> wrote: > > >>>>> Hi, > > >>>>> Do you plan to release your work as open-source (hopefully under > >>>>> Apache 2 to be compatible with the rest of Android)? > > >>>>> Best Regards, > >>>>> Gergely > > >>>>> On Sat, Jan 2, 2010 at 6:48 PM, Philippe Hausler <[email protected]> > >>>>> wrote: > >>>>>> Thanks for the feedback! I am quite familiar with Cocotron, very cool > >>>>>> project (albeit that it could use some commercial support to drive > >>>>>> more time devoted to development). So far with my tinkering the > >>>>>> compiler fully works, and I have been able to construct from scratch > >>>>>> some of the base classes from Foundation and UIKit. My approach was to > >>>>>> build a static library housing some of the base calls to load a JNI > >>>>>> app that has hooks peering into the base structures of my Foundation > >>>>>> and UIKit classes. Ideally I would like to have the libraries loadable > >>>>>> to a path e.g. /system/Library/Frameworks/Foundation.framework/ > >>>>>> Foundation.so to more closely mimic the loading schemes used in the > >>>>>> iPhone (this would provide more seamless integration between the > >>>>>> "port" and the "original platform"). However this does not seem to be > >>>>>> a valid place to keep them. The /sdcard path is writeable but for some > >>>>>> reason the System.load does not want to load libraries from that > >>>>>> location. So right now the biggest hurdle is where can I store a > >>>>>> shared library that might be utilized by many applications? So far my > >>>>>> code for Foundation and UIKit is fairly small, but I could see where > >>>>>> the library may reach a point at which it would be cumbersome to > >>>>>> require anyone who downloads an application that uses this to have to > >>>>>> download the entire library for each application (these are mobile > >>>>>> devices and memory space is limited). > > >>>>>> So far I think I can keep most of the heavy lifting to create the full > >>>>>> API level runtime in c/obj-c instead of having to do the majority of > >>>>>> the work in Java, but for the UI it is most likely that classes such > >>>>>> as UITextView would have a binding to a jobject pointer to a > >>>>>> android.view.TextView object. The Android platform has some nifty > >>>>>> features like the override methods for theming, I could see where this > >>>>>> advantage might cause some consistency issues with objc iPhone ported > >>>>>> apps if the UIKit classes did not utilize their Java counterparts. And > >>>>>> as per using the existing libraries from the iPhone, this is flat out > >>>>>> not doable, there is a slew of platform issues that would prevent > >>>>>> this, first and foremost the devices are different CPUs (the droid is > >>>>>> an ARMv5te? and the iPhone is ARMv6), second off the iPhone is mach-o > >>>>>> where as the android is ELF so the application architecture is > >>>>>> different from the ground level, direct binary compatibility is not > >>>>>> feasible. As I had mentioned before, I have gcc built to compile objc > >>>>>> for Android, as well as the libobjc.a. > > >>>>>> I had not seen the XMLVM project. Quite interesting, however it seems > >>>>>> after briefly looking at it that is the reverse direction, it takes > >>>>>> the Java VM bytecode and creates native machine bytecode, the reverse > >>>>>> ala llvm -> conversion -> jasmin might be doable but I think might > >>>>>> require more work than its worth to port the libraries into a pure > >>>>>> Java implementation that interfaces on that level. > > >>>>>> On Jan 2, 10:10 am, Gergely Kis <[email protected]> wrote: > >>>>>>> Hi Philippe, > > >>>>>>> It would be nice to be able to use Objective-C libraries on Android, > >>>>>>> e.g. to port IPhone applications. > > >>>>>>> Have you looked at Cocotron (http://www.cocotron.org/)?Theyhavean > >>>>>>> implementation of various Cocoa frameworks that work on both Windows > >>>>>>> and Linux. I don't think they started to work on UIKit or IPhone > >>>>>>> specific parts. > > >>>>>>> I don't think that the Android platform will have ObjC support > > ... > > Erfahren Sie mehr »
-- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
