Pushing on a CLOSED TREE since Android build only.
--HG--
extra : rebase_source : cc99efa734d1f4738d3f026c930a4d1955723783
extra : amend_source : 52c07807a77f263d2eb2593826dc0285928d9be4
This handles:
list.0=A
list.1=B
list.sublist.0=C
so that
list=>[A, B]
list.sublist=>[C]
and
dict=default
dict.key1=A
dict.key2=B
so that
dict=>{key1:A, key2:B}
dict=>default
--HG--
extra : rebase_source : 2c8f5941d2fca9c56b3858d3e98078a43fa69090
DONTBUILD NPOTB on a CLOSED TREE
This was tested by ally and mfinkle in #mobile.
--HG--
extra : amend_source : 5dd061d6ef98f49cb232baa7221ec514a32eeeee
This does two things. First, it aligns the brew formula name
(AndroidNdk) with the brew file name (android-ndk.rb). Second, it
makes sure that we actually find the android-ndk.rb file. I think
|mach bootstrap| always worked, due to a felicity where the working
directory always contained android-ndk.rb; but |python bootstrap.py|
failed because android-ndk.rb was downloaded to a temporary location
that was not included in the |brew install| command.
--HG--
rename : python/mozboot/mozboot/android-ndk-r8e.rb => python/mozboot/mozboot/android-ndk.rb
extra : rebase_source : 44f164d3d5916bc2faf4c64285e232047daea35e
This addresses issues with offline builds - due to pip latest version checking
Source archive downloaded from
https://pypi.python.org/packages/source/v/virtualenv/virtualenv-12.0.5.tar.gz
and uncompressed into python/virtualenv. The egg-info directory was
removed.
--HG--
extra : amend_source : 30a79486d91d9f79a36535eab438c0cd6f81daf3
Writing the unified files is another thing that will have to be moved
out of recursivemake.py eventually. And it doesn't belong inline amidst
makefile rules and variables. Move its logic to a separate function as
well.
_add_unified_build_rules does quite a lot of work besides adding
makefile rules and variables. The divying up of source files into
unified files is one part of that, so move it out into its own function.
When we eventually move that computation out of recursivemake.py, this
refactoring will make it easier to verify that's what we've done.
terminal.py had an ambiguous |import logging| that was importing
mach.logging from Sphinx. We fix it.
There was also a poorly formed link in the mach commands documentation.
We fix it.
--HG--
extra : rebase_source : 12783c69027989ac031d29e4ecbc1ee2f465ffa4
extra : histedit_source : 4283c6cdecc4de8aa7636d0c4cc566daf5142b50
Python API documentation requires the ability to import modules. So, we
set up a virtualenv in our Sphinx environment so module loading works.
This solution isn't perfect: a number of modules fail to import when run
under sphinx-build.
--HG--
extra : rebase_source : fce732e0b8aefe0e9a2ee594b8a08ac02e27579a
extra : histedit_source : bef27c947b95c3182fbc6cd656ae8c96acaaa6f4
Previously, code for staging the Sphinx documentation from moz.build
metadata lived in a mach command and in the moztreedocs module. This
patch moves the invocation to the Sphinx extension.
When the code is part of the Sphinx extension, it will run when executed
with sphinx-build. This is a prerequisite to getting RTD working, since
sphinx-build is the only supported entrypoint for generating
documentation there.
With this patch, we can now invoke sphinx-build to build the
documentation. The `mach build-docs` command is no longer needed.
--HG--
extra : rebase_source : 86e76c7d598ffa23dae858254eecedbdd12706a4
extra : histedit_source : 1826aa5ddfafdff62847cc293d1f0950b236caac
The recursivemake backend knows how to do several things with the IPDL
sources:
1) Determine the C++ sources that will be generated from given IPDL
sources.
2) Write out all the makefile rules and variables for said sources.
The first part isn't unique to the recursivemake backend; other backends
would eventually like to know what C++ sources come from IPDL source
files for easier cross-referencing purposes, etc. Let's take a first
cut at moving things into CommonBackend. (This may not be the best
interface, since it relies on consume_finished being invoked, and not
all backends call CommonBackend.consume_finished. Still, it's a start.)
psutil 2.1.3 is replacing psutil 1.0.1. There are numerous bug fixes and
feature enhancements in psutil worth obtaining.
Source code was obtained from
https://pypi.python.org/packages/source/p/psutil/psutil-2.1.3.tar.gz and
uncompressed into python/psutil without modification except for the
removal of the egg-info directory and the .travis.yml file.
--HG--
extra : source : 697eb6db7d96dc21e817cd27a7e46ed4ab00f9bb
psutil 2.1.3 is replacing psutil 1.0.1. There are numerous bug fixes and
feature enhancements in psutil worth obtaining.
Source code was obtained from
https://pypi.python.org/packages/source/p/psutil/psutil-2.1.3.tar.gz and
uncompressed into python/psutil without modification except for the
removal of the egg-info directory and the .travis.yml file.
--HG--
extra : rebase_source : 90b02e514e5dd1249d97d83223ef8fcf20c9da94
extra : histedit_source : 2e96344e1796b6156ccf279684687b2e8995be92
Source archive downloaded from
https://pypi.python.org/packages/source/v/virtualenv/virtualenv-12.0.2.tar.gz
and uncompressed into python/virtualenv. The egg-info directory was
removed.
--HG--
extra : rebase_source : e96572c694b2e780ed143a08b3c6670273a39fdb
extra : histedit_source : 17d490c968fdadd4dacad3b880bfcb1fc7b3e148
Pushing on a CLOSED TREE because this is NPOTB.
The custom brew formula is a lightly edited version of an earlier
revision of brew's android-ndk.rb. It's not clear that using a custom
brew formula for the Android SDK version r8e is better than using the
existing android Python module for installing the SDK and the NDK, but
it's done now and works locally. If we really wanted to avoid shipping
it, we could probably arrange to land it in
https://github.com/Homebrew/homebrew-versions.
I see no easy way to install the Java 1.7 JDK with macports, so in the
spirit of the good now being better than the perfect later, I've
punted. (I don't see an Android NDK package either, but that
functionality exists in Python.) Patches wanted!
--HG--
extra : rebase_source : d3ca836951b05eb30fabc17e523676d31c1ec0ef
extra : amend_source : d34e9eb5cd840b827a7ce65a0d22c1c275efff09
This prepares the way for implementing install_mobile_android_packages
on OS X.
--HG--
extra : rebase_source : b52b7080f857e351e71f169f09a42dfd61b43a43
This adds a generic android Python module that handles:
* downloading and unpacking Google's Android SDK and NDK bundles;
* using the |android| tool to install additional Android packages;
* printing a mozconfig snippet suitable for mobile/android builds.
--HG--
extra : rebase_source : abaffcee70eacb391f53d622fba4a445277818db
This lays the foundation for adding support for bootstrapping
mobile/android.
* Queries for which application to bootstrap, currently browser or
mobile/android;
* Adds call to install_APPLICATION_packages after
install_system_packages;
* Adds call to suggest_APPLICATION_mozconfig after bootstrapping
everything;
* and splits install_browser_packages out of install_system_packages
throughout (essentially untested, but generally simple).
To implement a new application (b2g?), just add it to the list of
applications and implement install_b2g_packages throughout.
--HG--
extra : rebase_source : 8c9b4485dbe5ceb64436fd73ea0258592a2b818f
Various bits of the test harnesses key off of mozinfo.info.get('asan');
we will need a similar switch for finding out whether this build
supports tsan.
Now that the mozbuild backend knows about FINAL_TARGET, we are able to
install generated xpt files into their final location. This saves us
from copying xpt files into their final location on every build.
Original patch by gps, rebased and comments addressed by Ms2ger
--HG--
extra : transplant_source : %E2%DC%0F%E0%AD%C2%25%A1%B8%A9%FE%B0%8C%60%FF%CB%02G%25%E5
mopack.BaseFile.copy() performs a generic read/write file copy. Windows
has an explicit CopyFile() call that tests have shown to be
significantly faster. Let's use that instead via the magic of ctypes.
Having SOURCES and its close relatives go through VariablePassthru
objects clutters the handling of VariablePassthru in build backends and
makes it less obvious how to handle things that actually get compiled.
Therefore, this patch introduces four new moz.build objects
corresponding to the major variants of SOURCES. It looks like a large
patch, but there's an ample amount of new tests included, which accounts
for about half of the changes.
An upcoming patch will reuse this code. Split it out into its own
function.
--HG--
extra : rebase_source : 2057266a1ed4d86b1ca857712cd279bdfbd32148
extra : histedit_source : 8f2b7ec06e5b72ab08586902c51c3025a53259e6
With this patch, we now have the ability to declare mach sub-commands.
Subsequent patches will implement dispatching for sub-commands.
--HG--
extra : rebase_source : 32a672ff3ba7a1a1c8c27dff3fe657dec08e3569
extra : histedit_source : 2bb2c27ae0e2dab052a6ef93b0a70f488f8cd56e
We will soon have proper sub-commands. Let's fix function names.
--HG--
extra : rebase_source : 1cb0c008ecc0d2159dd799e76adad4892d65f119
extra : histedit_source : 9472b2d2609224b011eca04385cf9d5a49986864
mach conditions are implemented elsewhere. This comment can die.
--HG--
extra : rebase_source : c956d5af7858d997a1f49f3b24bb54e5f8a52240
extra : histedit_source : 76b8155b12ab0ea86e16e807b1c6f691cb8f3640
Documentation was referencing sub commands. The proper terminology is
"command."
--HG--
extra : rebase_source : aa2fc73c6141850109324fd5299491e49ef29e91
extra : histedit_source : da075bea5a36a9de81527d93a9fc751cd6cae9b2
There were a few parts of the docs that were linking to Python types
incorrectly. Let's fix that.
--HG--
extra : rebase_source : 374be660084727eba1ce9181c2abf384f40eeb82
extra : histedit_source : bfa8de9b7a277666d92ebe71cd64ffed96628518
