On 30 Jun 2014, at 18:37, Dave Hylands <[email protected]> wrote:
> Hi Chris > > * Knowing your way around the B2G build system - it would be great to > > provide a really detailed view of how it works, what it does at each stage, > > etc. So that developers can help with it, and fix building problems as they > > arise (there's been a lot of traffic on the mailing list about this kind of > > thing recently.) > > The B2G build system is really just the android build system. > > > > gonk/misc/Android.mk is where we have a target called gecko, which in turn > > calls make to build gecko. > > There is also a target called profile.tar.gz defined in gaia/Android.mk > > > > Everything inside gecko then gets built using normal gecko procedures > > Everything inside gaia gets built using Android.mk and/or Makefile > > > > The rest is pretty much built using android build. > > We’ve got a fair bit of this already, in different places, but I’m sure we > could organize them better, and provide a more detailed description of what > happens, how it differs form Android build, how it’s the same, etc. > It would be great to be able to answer all these mails we get on dev-b2g > saying things like “this sucks: I tried to build for the Open C and bricked > my phone. Your instructions weren’t good enough. > > So that doesn't really have anything to do with the build system. Yeah, sorry - it is. Although I’m sure a fair number of people perceive it as being the same thing. > > Unfortunately, in many cases, unbricking a phone involves using some Windows > vendor tool to flash an image. And we're not authorized to redistribute the > flashing tool, nor the images that could help out. So, in many cases our > hands are tied, and the user needs to go to the vendor to get their phone > unbricked. Yeah. It is a such a pain though that we can’t do more to help. And doing more could be damaging, as it then sets up unrealistic expectations wrt how much support we can and should be expected to give. > > And for what can be done, each phone typically requires a specialized set of > instructions. Somebody has to create these, and maintain them as changes > occur. This is what I’m trying to do on https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide, but it is so hard to find all the bits of info, and make sure it is helpful. The Flame, at least, has been easy in this regard ;-) > > > > * What other B2G customizations can be done that are useful to talk about? > > What kinds of customizations? I suspect that there are many ways of > > customizing things, from prefs, to adding native code, and/or adding > > default apps. > Yeah - there are bits and pieces all over the place. So creating someplace > central to start would probably be good. > > > I really don’t know what else. Whatever else we think might be worth telling > the community about. Whatever might be productive for them to help with. > > > I have started a google doc at > > > > https://docs.google.com/a/mozilla.com/document/d/1Wn-nQSHCxJnudyA0XgkVORpCGGBMUW6fOosxEXMkZ8Y/edit# > > > > Where I have started to collect useful notes. Please feel free to leave > > comments here, or reply to this mail. > > > > I'd really love some team members who are experienced in these areas to > > give me some help on putting together some truly useful docs. > > Why a google doc and not a wiki page? No great reason; I guess it’s just the way I do things. I tend to think of MDN pages and WikiMo pages as being somewhat more permanent than Etherpads and Google docs. If I am writing something that will persist for a while, then I use the former methods, but if I just want to develop some ideas in a temporary space that will then be fed into a different, more permanent resource later - which is what we are doing here - then I use one of the latter methods. _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
