Hey all,
Do any of you have experience working with the more advanced aspects of
the 'repo' tool such as the --depth=1 argument to 'repo sync' for
shallow git clones or the 'groups' attribute of the 'project' XML
element in the manifests for targeted 'repo init' invocations?
Note that I have not yet fully understood the build so that these
questions might well arise from misunderstanding. (This all started
as an attempt to improve the docs but that proved impossible
without digging deep into the 'B2G' world, which has now turned
into an effort to clean up the 'B2G' workspace and the scripts
driving the build.
It seems there might be room for a better use of 'repo'.
The 'repo' tool apparently allows shallow clones. The 'repo sync'
command accepts a --depth=1, which should eventually get passed to 'git
clone' and thence to 'git fetch' leading to shallow clones of all the
projects included in the 'repo init'. If this could work, it would be of
great use to most of us since almost none of us are actually hacking in
all of the 'repo' projects within our workspace. I believe that git
allows a shallow clone to later be expanded to a full clone; if so, we
could do a shallow clone of all projects by default, then explain how to
get the full clones later for developers working with specific projects.
(My experiments on this are on hold pending the activation of my new
'unlimited' internet connection plan, which might happen today.)
The 'repo' tool also apparently allows the 'projects' to be grouped into
named groups so that 'repo init', when given a group name, will
originally load only the projects in that group. Given the diverse user
base that Firefox OS is gaining, it seems we might be able to leverage
that to allow:
- gaia only builds (with file copy to device)
- gaia and gecko only builds (with file copy to device)
- full system.img and userdata.img builds (with flash to device)
- Android tool builds: (adb, fastboot, mkbootimg) builds
- gonk builds: boot.img, (with flash to device)
- Desktop tool builds: whatever those runtime and profiling tools
are really about.
The idea is to minimize the download size and build complexity for those
users who don't need it. We could use the 'groups' attribute to make,
say a 'gaia' group that has only the
- B2G build (a fork of the 'ndk' project, needed in all groups)
- ?some build glue taken from gonc-misc?
- gaia
and then a user who has acquired an 'adb' binary from somewhere can copy
the new gaia files over. That's my current hope. However, its now clear
I need to dig into the 'gonk-misc' project to see what glue it is
bringing to the 'ndk' build system and so it seems worth asking for
advice/pointers. Do any of you who have written this code have a sense
of how we could modularize the build of the Firefox OS components into
such 'repo' groups? Have you tried this?
This is part of my work developing a workspace and management system for
Firefox OS which is both clean enough for me to be able to work within
and clear enough for me to feel like documenting. It is also obvious
that the growth of Firefox OS has lead to a greater variety of users
than originally present:
* enthusiasts that want a new build,
* crazed enthusiasts that want to customize their own build and
the splash screens, ringtones and other goodies,
* web app developers that need a new build to use Firefox Dev tools
or to tackle bugs,
* gaia developers who need to stay current,
* gecko/gonk developers doing their thing,
* developers targeting new hardware devices,
* distributors wanting to customize a distribution with splash
screens, ringtones, particular app bundles, ...
We are many, all with slightly different needs. The current B2G project
is a mess of scripts which becomes, after repo init, a mess of
directories. For my own needs, I want a clear separation between:
* workspace stuff,
* source code working directories, and
* compilation output.
As a bonus, I'm looking to lighten the downloads and target the build
for specific uses. So I am working on a new version of 'B2G' with a
cleaner layout, with a set of manifests which also use a clean layout,
and a workspace management system (bash script) which is modular for
extension but walks users through machine preparation, build
configuration, device backup, source code build, compile result
installation and possibly eventually runtime stuff (?profiling?) and
build customization. That's the grandiose plan.
The issue of the moment, however, is wrangling 'repo' and any advice on
that would be appreciated.
Thanks,
~adrian
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
