Snow leopard plans

[Al Sutton]

Just wondering if there are any plans to support Snow Leopard for the build process? I know it's out of the question for Donut, but I'm wondering if its' on the drawing board for Éclair.

(The reason I'm asking is that the Mac I build the open source repo SDKs on has a copy of Snow Leopard sitting next to it, which I'm taking as a subtle hint my wife wants to upgrade her machines OS :)).

Al.

--

* Looking for Android apps?, try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number  6741909. The registered head office is Kemp House,
152-160 City Road, London,  EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

[Romain Guy]

Is it not building on Snow Leopard?

--
Romain Guy
Android framework engineer
roma...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them

[Al Sutton]

http://source.android.com/download says; "At the moment MacOS 10.6 ("Snow Leopard") is not supported. "

 

I've not tried, but I don't want to upgrade the machine only to find I can't build the SDK any more.

 

Al.

 

--

* Looking for Android apps?, try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number  6741909. The registered head office is Kemp House,
152-160 City Road, London,  EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

 

[Romain Guy]

I'll try to find a better answer then.

BTW, I just downgraded my MacPro from Snow Leopard last night because it broke color profiles (and because of other issues.) You might want to read boards etc. to make sure the upgrade won't be a problem for you, no matter what the support level is with Android's source code.

[Al Sutton]

Thanks.

 

I've heard there are some issues and a .1 update is already doing the rounds of developers, so I'm planning to hold off for a bit anyway, but if it doesn't work with the Donut build and there are no plans to support it for Éclair I think I might end up scouring eBay for a second hand Intel Mac Mini.

[Chad Fawcett]

I believe the first issue that comes up is that Snow Leopard lacks Java 5, including just 32-bit an 64-bit versions of Java 6. I believe I saw a thread a while back mentioning the possibility of using a 1.5 language target for javac instead of a hard version check in the build process, so that might be the first step.

 

They also switched to gcc 4.2 instead of 4.0 as the default system compiler, but I haven't dug in yet to see if that or any other system library changes might be causing more issues.

 -Chad

[Al Sutton]

I've also found that installing from scratch uncovers a problem with libsdl not compiling in macports in snow leopard.

The macport guys know about it, and they've passed it to the libsdl guys who are backporting a fix.

Al.

[Kenny Root]

I had been gathering some notes about building the framework on 10.6
at http://the-b.org/Android#Development_Notes but apparently sometimes
you don't have gcc-4.0 after upgrading. A way of installing gcc-4.0
after having Snow Leopard would probably "complete" the solution.

Kenny

> >http://source.android.com/downloadsays; "At the moment MacOS 10.6  

> > ("Snow Leopard") is not supported. "
>
> > I've not tried, but I don't want to upgrade the machine only to find  
> > I can't build the SDK any more.
>
> > Al.
>
> > --
>
> > * Looking for Android apps?, tryhttp://andappstore.com/*
>

> > romain...@android.com

>
> > Note: please don't send private questions to me, as I don't have  
> > time to provide private support.  All such questions should be  
> > posted on public forums, where I and others can see and answer them
>
> > --
> > Romain Guy
> > Android framework engineer

> > romain...@android.com

[Al Sutton]

One of the problems I've got is that this isn't an upgrade. Its' on a
new Macbook Pro which only came with Snow Leopard.

Al.

[Chad Fawcett]

Do you know what you're missing on a fresh install versus an upgrade?

[Al Sutton]

I'm stuck at the MacPorts stage because of this bug;

http://trac.macports.org/ticket/20235

It looks like there has always been problems with sdl on 64-bit Mac OS X, and Snow Leopard has just forced the issue.

Al.

--

* Looking door Android Apps? - Try http://andappstore.com/ *

======

Funky Android Limited is registered in England & Wales with the 

company number  6741909. The registered head office is Kemp House, 

152-160 City Road, London,  EC1V 2NX, UK. 

The views expressed in this email are those of the author and not 

necessarily those of Funky Android Limited, it's associates, or it's 

subsidiaries.

[Shawn Brown]

On Sun, Sep 13, 2009 at 10:19 AM, Chad Fawcett <chadf...@gmail.com> wrote:
> I believe the first issue that comes up is that Snow Leopard lacks Java 5,
> including just 32-bit an 64-bit versions of Java 6. I believe I saw a thread
> a while back mentioning the possibility of using a 1.5 language target for
> javac instead of a hard version check in the build process, so that might be
> the first step.

Google Webtoolkit also does a check and what many users did there was
to copy over java 5 from leopard

Of course whether such a change would survive a system update and how
to update the java for bug fixes are other questions but...

http://wiki.oneswarm.org/index.php/OS_X_10.6_Snow_Leopard

[David Turner]

Try setting up your machine without installing sdl if possible.
I think that the SDL requirement was for previous versions of the emulator, and doesn't apply anymore (crossing fingers)

[Al Sutton]

I'm giving it a spin now.

As a side note Xcode on Snow Leopard has the right version of gmake
(3.81) so it's one less thing to pull in from macports :).

Al.

On Sep 16, 11:08 pm, David Turner <di...@android.com> wrote:
> Try setting up your machine without installing sdl if possible.
> I think that the SDL requirement was for previous versions of the emulator,
> and doesn't apply anymore (crossing fingers)
>
>
>
> On Tue, Sep 15, 2009 at 4:47 AM, Al Sutton <a...@funkyandroid.com> wrote:
> > I'm stuck at the MacPorts stage because of this bug;
> >http://trac.macports.org/ticket/20235
>
> > It looks like there has always been problems with sdl on 64-bit Mac OS X,
> > and Snow Leopard has just forced the issue.
>
> > Al.
>
> > --
>

> > * Looking door Android Apps? - Tryhttp://andappstore.com/*

>
> > ======
> > Funky Android Limited is registered in England & Wales with the
> > company number  6741909. The registered head office is Kemp House,
> > 152-160 City Road, London,  EC1V 2NX, UK.
>
> > The views expressed in this email are those of the author and not
> > necessarily those of Funky Android Limited, it's associates, or it's
> > subsidiaries.
>

> > On 15 Sep 2009, at 03:02, Chad Fawcett wrote:
>
> > Do you know what you're missing on a fresh install versus an upgrade?
>
> > On Mon, Sep 14, 2009 at 7:34 AM, Al Sutton <a...@funkyandroid.com> wrote:
>
> >> One of the problems I've got is that this isn't an upgrade. Its' on a
> >> new Macbook Pro which only came with Snow Leopard.
>
> >> Al.
>
> >> On 13 Sep 2009, at 16:25, Kenny Root wrote:
>
> >> > I had been gathering some notes about building the framework on 10.6

> >> > athttp://the-b.org/Android#Development_Notesbut apparently sometimes

[Al Sutton]

Next problem is, of course, the java version.

The donut build script stops dead saying 1.6.0_15 is incorrect and it
wants 1.5 :(.

Al.

On Sep 16, 11:08 pm, David Turner <di...@android.com> wrote:

> Try setting up your machine without installing sdl if possible.
> I think that the SDL requirement was for previous versions of the emulator,
> and doesn't apply anymore (crossing fingers)
>
>
>
> On Tue, Sep 15, 2009 at 4:47 AM, Al Sutton <a...@funkyandroid.com> wrote:
> > I'm stuck at the MacPorts stage because of this bug;
> >http://trac.macports.org/ticket/20235
>
> > It looks like there has always been problems with sdl on 64-bit Mac OS X,
> > and Snow Leopard has just forced the issue.
>
> > Al.
>
> > --
>

> > * Looking door Android Apps? - Tryhttp://andappstore.com/*

>
> > ======
> > Funky Android Limited is registered in England & Wales with the
> > company number  6741909. The registered head office is Kemp House,
> > 152-160 City Road, London,  EC1V 2NX, UK.
>
> > The views expressed in this email are those of the author and not
> > necessarily those of Funky Android Limited, it's associates, or it's
> > subsidiaries.
>

> > On 15 Sep 2009, at 03:02, Chad Fawcett wrote:
>
> > Do you know what you're missing on a fresh install versus an upgrade?
>
> > On Mon, Sep 14, 2009 at 7:34 AM, Al Sutton <a...@funkyandroid.com> wrote:
>
> >> One of the problems I've got is that this isn't an upgrade. Its' on a
> >> new Macbook Pro which only came with Snow Leopard.
>
> >> Al.
>
> >> On 13 Sep 2009, at 16:25, Kenny Root wrote:
>
> >> > I had been gathering some notes about building the framework on 10.6

> >> > athttp://the-b.org/Android#Development_Notesbut apparently sometimes

[Jean-Baptiste Queru]

You can disable the check for your local build (at least for the
purpose of seeing what'll fail next).

The concern with java 1.6 is that even in 1.5-compatible mode it
accepts code that it rejected by java 1.5 (so people building with 1.6
tend to break the build for the people working with 1.5).

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Chad Fawcett]

Yes, skipping the java check gets you farther along...the next issue that I see on my system at a glance looks similar to what I think people ran into getting things working on 64 bit ubuntu re: mixed architecture ld linking issues. This is minimal hobby hours fiddling only for me, so that's as far as I've gotten and could be way off still so grain of salt and all that. 

For java 1.5 vs 1.6 issues, is it mainly just the @override bug? To ask the obvious, I'm assuming that neither -source 1.5 nor -target 1.5 for javac catches that particular issue.

 -Chad

[Jean-Baptiste Queru]

Yes, the issue is that java 1.6 allows to @override an interface
method even with -source 1.5 (and -target 1.5 which shouldn't matter
in that case), whereas 1.5 doesn't.

As crazy as it sounds, a checker that would only be run with java 1.6
that'd barf when it finds such an override might be a horribly elegant
way to allow building with either 1.5 or 1.6.

JBQ

[Al Sutton]

Given that sun are making it harder and harder to get a 1.5 SDK (as
they're EOLing it in the next month or two), and the last time I
installed Ubuntu the 1.5 SDK had been removed from their apt repos,
isn't it time to move to 1.6?

Al.

> ...
>
> read more »

[Jean-Baptiste Queru]

Moving to 1.6 would condemn MacOS 10.4.

JBQ

[Al Sutton]

If you look at what Sun have done to the 1.4 JDK (http://java.sun.com/
j2se/1.4.2/download.html) you'll get an idea of what'll be happening
to the 1.5 JDK for Windows and Linux iwhen it hits its' EOSL at the
end of next month.

I know that Apple were slow off the mark with a 1.6 JDK, but sticking
to 1.5 is, in the near future, going to make it painful for any
developer getting a new machine or developers with newish machines
coming to Android development (most Java developers I know on Windows
& Linux have already made the transition to the 1.6 JDK and so would
need to hunt down a 1.5 one).

What I'd suggest is that as we're looking at several months before the
next release (by which time 1.5 will be will past its' EOSL marker),
and that donut is out the door and in a feature freeze, it's probably
the best opportunity we're going to get to start to make the
transition.

Al.

> ...
>
> read more »

[Jean-Baptiste Queru]

AFAIK there's no problem using a 1.6 JDK for SDK-level development
(even if the SDK itself is built with 1.5).

Platform-level is different, because moving to 1.6 would force future
Mac SDKs to be built on 10.5, and SDKs built that way don't work on
10.4 (for a reason that's unrelated to java). So, because of that, we
need to continue being able to build the platform with 1.5.

Fundamentally, if there was a tool to reject source code that doesn't
compile with 1.5, there's be no good reason to prevent people from
building with 1.6.

JBQ

[Al Sutton]

One of my concerns is that Sun doesn't say the Windows 1.5 JDK is
supported on Windows 7, and says it's only supported on SuSE up to 10.

If you combine that with Snow Leopard only have a 1.6 JDK available
from Apple, it means that in a couple of months the vendor
recommended versions of all the OSes that the SDK supports will not
have an "officially approved" JDK available that you can do platform
development or SDK compiles with.

I know that's not to say it won't work, but it just concerns me that
if something does go wrong then it could be a can of worms.

Hopefully by the time the Eclair tree stabilises something will have
been sorted out :).

Al.
--

* Looking door Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

[Jean-Baptiste Queru]

Like I said, this isn't a concern for the SDK. There's no problem
using 1.6 when developing with the SDK. The problems arise for people
working at the platform level.

JBQ

[Chad Fawcett]

(kind of gone the way of 1.6 vs 1.5 instead of specifically snow leopard, but...)

My first thought was that an annotation processor might be able to fit the bill, but while it could find the @override instances, it seems like you really need to use reflection to determine whether or not it's a superclass or interface method that has the annotation, and I'm not sure a processor can go that deep...

Java is far from my bread and butter, so I could be missing something here..but it sounds like to allow 1.6 but still support 1.5 and avoid build issues one would need a reflection tool that's called after javac (when building with 1.6). Said tool dynamically loads up the .class's classes after compilation, checks all of the method annotations for @override, and if it sees one then checks to make sure the superclass has said method signatures (being sure to check all methods, not just declared ones). If one is missing, that means it's an interface method (since i think the javac compile would have failed if it was neither), so throw an error. 

Am I missing something on the 1.6 issue front?

 -Chad

[Jean-Baptiste Queru]

My gut feeling is that 1.6 vs 1.5 is actually the area that needs some
decision and discussion, and it's in fact not specific to MacOS, as we
expect the next Ubuntu LTS to also lack Java 1.5. I'm not saying
that's the only issue, but I'd guess that the other situations with
10.6 won't need to be resolved through tough decisions: it'll just be
a matter of "fixing things that are broken".

That sounds like an approach indeed. Since the standard Android build
process already runs dx right after javac, that might be a good place
to put this, assuming that there's still enough information at that
point to do it.

My first instinct (as a C guy, actually) was originally to start from
a (hypothetical) java lexer and parser, and to write a tool that'd
walk the parse tree to find that information. Of course, that idea
doesn't work, since the information about whether a function comes
from the parent class, from an interface, or from the class being
compiled is not available in the source code (unlike in C/C++), and
therefore is not in the parse tree. So, either that tool needs to also
know how to parse the class files in the relevant jars, or this
approach is doomed.

JBQ

[Tom Gibara]

Yes, it's actually very easy to do the verification excluding external dependencies (ones that aren't in the source path). Just hijack javadoc to do the work. Below is a doclet that does that work. Whether javadoc can be prodded into considering binary dependencies, or if all the relevant source code could be analyzed in a single pass, I don't know.

(the class below would be invoked via javadoc, something like javadoc -doclet OverrideCheck ...)

>>>>>>>>

import com.sun.javadoc.AnnotationDesc;

import com.sun.javadoc.ClassDoc;

import com.sun.javadoc.Doclet;

import com.sun.javadoc.MethodDoc;

import com.sun.javadoc.RootDoc;

public class OverrideCheck extends Doclet {

private static final String OVERRIDE_ANNOTATION_TYPE = "java.lang.Override";

public static boolean start(RootDoc root) {

ClassDoc[] classes = root.classes();

for (ClassDoc clss : classes) {

MethodDoc[] methods = clss.methods(false);

for (MethodDoc method : methods) {

AnnotationDesc[] annotations = method.annotations();

boolean override = false;

for (AnnotationDesc annotation : annotations) {

override = annotation.annotationType().qualifiedTypeName().equals(OVERRIDE_ANNOTATION_TYPE);

if (override);

}

if (override) {

ClassDoc over = method.overriddenClass();

if (over == null) {

System.out.println("WARNING: " + clss.name() + "." + method.name() + " OVERRIDES UNKNOWN");

} else if (over.isInterface()) {

System.out.println("ERROR:   " + clss.name() + "." + method.name() + " OVERRIDES INTERFACE " + over.name());

}

}

}

}

return true;

}

}

>>>>>>>>

2009/9/18 Jean-Baptiste Queru <j...@android.com>

[Jean-Baptiste Queru]

Woah, cool, there's some actual progress being made :)

(this is way over my level, but I'd like to believe that this can be
made to work).

JBQ (starring this discussion to be sure he doesn't forget about it)

[Tom Gibara]

Just have two things to add (I feel like I've steered this thread hopelessly off course, but I don't think this follow-up merits a separate thread):

1) Having tested the code I posted earlier and I've realized my first attempt has some obvious and dumb bugs. It's okay as POC but beyond that it's rubbish.

2) I've done some experimenting with javadoc and this approach seems really promising. I can't find any relevant documentation, but it appears that compiled java classes supplied to the javadoc tool via the classpath are folded into it's model of the code hierarchy, which means that it's possible to distinguish an "implementation" from an "override" across the source/binary boundary.

I've never taken the time to understand the build process, but if what I've understood from reading this thread is correct, I think running a small doclet (similar to the one above) would be sufficient.

I'll try to put together a working implementation and post it to a new thread.

Tom.

2009/9/18 Jean-Baptiste Queru <j...@android.com>

[Chad Fawcett]

Here's what I'm currently doing to build on 10.6 (without rosetta or java 1.5):

* Include 10.4 support when installing the OS X developer tools.

* For MacPorts, libsdl/libsdl-devel and gmake are no longer needed,  so my MacPorts setup was:

    POSIXLY_CORRECT=1 sudo port install git-core gnupg

A few change pulls, from platform root after a repo sync:

------------

cd system/core && git pull git://android.git.kernel.org/platform/system/core refs/changes/45/11845/2 && cd ../..

cd external/qemu && git pull git://android.git.kernel.org/platform/external/qemu refs/changes/46/11846/2 && cd ../..

cd prebuilt && git pull git://android.git.kernel.org/platform/prebuilt refs/changes/14/12014/1 && cd ..

cd prebuilt && git pull git://android.git.kernel.org/platform/prebuilt refs/changes/75/12075/1 && cd ..

cd build && git pull git://android.git.kernel.org/platform/build refs/changes/74/12074/1 && cd ..

cd build && git pull git://android.git.kernel.org/platform/build refs/changes/93/12093/1 && cd ..

-------------

touch external/webkit/WebCore/css/tokenizer.flex

Then make as usual.

(I don't now that touch is required for all or just a lingering symptom on my environment from before flex prebuilt was updated to a runnable binary, but it doesn't hurt. Fixes the build issue by making sure tokenizer.flex is re-processed.)

 -Chad

[Chad Fawcett]

Oops, ignore/delete that last git pull for 12093. Unrelated to 10.6, possibly outdated by now/unneeded.

[Joel Reymont]

On Oct 5, 9:40 pm, Chad Fawcett <chadfawc...@gmail.com> wrote:
> cd system/core && git pull
> git://android.git.kernel.org/platform/system/corerefs/changes/45/11845/2

Is this still valid? I get an error when pulling:

pushd system/core && git pull git://android.git.kernel.org/platform/system/corerefs/changes/45/11845/2
/Volumes/android/mydroid/system/core /Volumes/android/mydroid
fatal: The remote end hung up unexpectedly

[Joel Reymont]

On Oct 5, 9:40 pm, Chad Fawcett <chadfawc...@gmail.com> wrote:

> cd system/core && git pull
> git://android.git.kernel.org/platform/system/corerefs/changes/45/11845/2
> && cd ../..

Apologies for the noise, spaces are missing before 'refs'.

[Joel Reymont]

I managed to build everything on Snow Leopard using Chad's
instructions.

I get a blank screen with the words ANDROID when I run the emulator,
though, e.g.

emulator -sysdir /Volumes/android/mydroid/out/target/product/generic -
kernel /Volumes/android/mydroid/prebuilt/android-arm/kernel/kernel-
qemu -system /Volumes/android/mydroid/out/target/product/generic/
userdata.img

Any suggestions on how to troubleshoot this?

Thanks, Joel

[Joel Reymont]

Just to add to what I said before, I do let the emulator run for a few
minutes but the home screen never comes up.

adb lists the emulator as offline:

adb devices
List of devices attached
emulator-5554 offline

and after a while it stops listing the emulator at all.

'adb logcat' says it's waiting for devices.

How do I troubleshoot this?

This is, again, a Snow Leopard source build that I run like this:

emulator -sysdir /Volumes/android/mydroid/out/target/product/generic -
kernel /Volumes/android/mydroid/prebuilt/android-arm/kernel/kernel-
qemu -system /Volumes/android/mydroid/out/target/product/generic/
userdata.img

I did build the SDK with 'make sdk' if it matters.

Thanks, Joel

[Christopher Tate]

When you run the emulator, supply the command line flag

-logcat "*:v"

and see if it ever prints anything. That will replicate the 'adb
logcat' text on the emulator's stdout.

-- chris tate

[Joel Reymont]

On Oct 7, 2009, at 8:46 PM, Christopher Tate wrote:

> When you run the emulator, supply the command line flag
>
> -logcat "*:v"
>
> and see if it ever prints anything. That will replicate the 'adb
> logcat' text on the emulator's stdout.

It doesn't print anything at all.

emulator -sysdir /Volumes/android/mydroid/out/target/product/generic -
kernel /Volumes/android/mydroid/prebuilt/android-arm/kernel/kernel-
qemu -system /Volumes/android/mydroid/out/target/product/generic/

userdata.img -logcat "*:v"
2009-10-07 20:47:33.965 emulator[52363:903] Warning once: This
application, or a library it uses, is using NSQuickDrawView, which has
been deprecated. Apps should cease use of QuickDraw and move to Quartz.
<nothing here after a few minutes>

---
fastest mac firefox!
http://wagerlabs.com

[Christopher Tate]

Yuck. That typically means that qemu isn't starting up at all.

[Joel Reymont]

On Oct 7, 2009, at 9:00 PM, Christopher Tate wrote:

> Yuck. That typically means that qemu isn't starting up at all.

How do I troubleshoot this?

---

[Chad Fawcett]

Android plain terminal font text with a blinking cursor or Android shiny metalic animated text?

 -Chad

[Joel Reymont]

On Oct 7, 2009, at 10:21 PM, Chad Fawcett wrote:

> Android plain terminal font text with a blinking cursor or Android
> shiny metalic animated text?

I have it up and running now. emulator ... -verbose helped point out
that it wasn't finding the image.

I put my notes here:

https://wiki.mozilla.org/User:Joel_Reymont/Android_Notes

Thanks, Joel

[Chad Fawcett]

For what it's worth, I generally start the repo emulator with an alias in my .bash_profile that is essentially:

ANDROID_PRODUCT_OUT=/path/to/mydroid/out/target/product/generic /patch/to/mydroid/out/host/yourbuildplatformhere/bin/emulator

the version from my .bash_profile:

alias launchAndroid='ANDROID_PRODUCT_OUT=/Volumes/AndroidWorkDrive/mydroid/out/target/product/generic /Volumes/Android/AndroidWorkDrive/mydroid/out/host/darwin-x86/bin/emulator'

as just running emulator usually kicks off the 1.6 sdk one from my tools path, which I don't want when playing with the repo build.

--

Chad Fawcett
http://twitter.com/chadfawcett

[Chad Fawcett]

https://review.source.android.com/12014

My only x86 mac is running Snow Leopard...does anyone have a 10.4 and/or 10.5 x86 dev box that wouldn't mind verifying that the flex binary in change 12014/2 still works for you?

(When I want to make sure the executable gets called during a build, "touch external/webkit/WebCore/css/tokenizer.flex" does the trick.)

-Chad