On 01/10/2015 05:04 PM, enh wrote:
> On Thu, Jan 8, 2015 at 10:55 AM, Rob Landley <r...@landley.net> wrote:
>> Since Toybox made it into Android, I just reinstalled my big machine
>> with Ubuntu 14.04 so I could actually add packages to it (such as the
>> java version the Android Open Source Project wants), and I have
>> downloaded AOSP (overnight, and I had to restart it in the morning), and
>> it is now compiling. (Wow, that's a lot of warnings...)
> 
> upload your patches to https://android-review.googlesource.com/ :-)

Actually my problem right now is I can't get the emulator to run.

> landley@halfbrick:~/android/aosp$ emulator
> emulator: WARNING: system partition size adjusted to match image file
> (550 MB > 200 MB)
>
> emulator: WARNING: data partition size adjusted to match image file
> (550 MB > 200 MB)
>
> SDL init failure, reason is: No available video device

I ran the build under "screen", which meant the session that the build
set a magic environment variable for didn't have access to X11. So I ran
another window that _did_ have an X11 context and that failed because it
didn't have the magic environment variable(s).

So then I tried:

> landley@halfbrick:~/android/aosp$ ANDROID_PRODUCT_OUT=/home/landley
> /android/aosp/out/target/product/generic prebuilts/android-emulator
> /linux-x86_64/emulator
> emulator: ERROR: You did not specify a virtual device name, and the
> system directory could not be found.
>
> If you are an Android SDK user, please use '@<name>' or '-avd <name>'
> to start a given virtual device (see -help-avd for details).
>
> Otherwise, follow the instructions in -help-disk-images to start the
> emulator

So then I started reading -help-disk-images (after a few minutes of
trying --help-disk-images and it not knowing what I was talking about
because normal --longopt syntax does not apply here), and that told me I
needed to manually specify at least 4 images (possibly 9 if you could
the writable .img files), so I started googling and
http://developer.android.com/tools/help/emulator.html told me I needed
to read http://developer.android.com/tools/devices/emulator.html which
told me I needed to read
http://developer.android.com/tools/devices/index.html which didn't
explain how the other context tried to just run it (stymied by X11 not
being connected up, not by being unable to find the build output)
without me needing to create a new thing or specify multiple files
manually on the command line...

Which is about the point I wandered away and did something else...

I should probably re-run the build so it can set up the magic
environment variables again (last time it took 5 hours), except then I
get one magic window that might run the emulator due to context I can't
reproduce, which seems... awkward. I would actually like to understand
it. (Or just boot the darn thing under vanilla qemu, which
prebuilt/.../emulator seems to be a fork of? I think?)

>> Does anybody know if there's an actual android operating system channel
>> on IRC? The  main #android one is mostly about application development
>> in java, and people reimaging their phones.
> 
> no idea, sorry.

I looked for a mailing list but the "discussion groups" link on
https://source.android.com/source/contributing.html leads to index.html
in the same directory. (And I'd probably need to create yet another
google account to connect, I think I lost the credentials to the
previous one again and the one I use for email is some funky "domain
account" thing a friend set up years ago that has some really strange
status and can't use most google services.)

>> Anyway, my short term goal is still to get Aboriginal Linux weaned off
>> of busybox, and then get Linux From Scratch built under the result. And
>> then _after_ that I need to take apart the AOSP build and figure out
>> what the minimal package set to get text mode running under the
>> emulator, and then try to get that rebuilding under itself.
> 
> traditionally there hasn't been one, but you can try
> qemu_arm-userdebug. it's _supposed_ to not include a VM or anything
> though i'm led to believe that right now it's building more than it's
> supposed to because some unwanted dependency crept in. still probably
> your best choice though.

I think I did build that. What config file stores the "lunch" answers I
gave? (The only dotfile I see in the directory is .repo. There's no
"output" directory. I can't do "git status" in the directory because it
says there's no git repo there. Currently running "repo status" on a
wild guess, but that's spent 2 minutes sitting there without producing
any output yet...)

Ah it eventually said "nothing to commit (working directory clean)".
There are a whole bunch of output files somewhere, and config files
somewhere else. I suppose some wiki page tells me where they are, maybe
I'll find it someday.

Might be easier to start reading from the top level Makefile on down,
let's see, that's a not-symlink to build/core/main.mk, which is a
thousand lines long...

>> This will almost certainly involve separating the build into layers the
>> way I described way back at:
>>
>> https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu?slide=91
>>
>> Because the current giant hairball? It's...
>>
>> I'm aware Google has the funding to make the Mongolian Hordes technique
>> work, but it doesn't seem quite optimal from a project scalability
>> perspectve. I haven't got nearly the familiarity necessary to criticize
>> yet, but _achieving_ the necessary familiarity is... daunting.
> 
> even just killing AndroidConfig.h (which gets -include'd in every file
> that's built) has taken a surprisingly large chunk of my time. (and,
> pretty much by definition, the stuff that's left is the hardest stuff
> to kill.) the tree is so large, and with so many different users, that
> it's pretty hard to make any change to the build. and there's usually
> something more urgent to do.

I know the feeling. :)

I'm prioritizing "doing it right" for toybox, but I added the "pending"
directory because I'm a huge bottleneck when I do that (cleaning up
printf.c just ate most of a week) and this is a place code can go
without being ignored/lost on the list.

Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to