Since CMake generated build systems can run cmake if necessary, this
will make it possible to pick up changes from the source directory if
any and resume as much of the build as possible.
This builds the foundation for removing the need to blow away any of the
work done by the previous runs of the script.
We try to generate a C++ constant for static final fields, but that
was failing for inaccessible fields. Now we set the field to be
accessible so that we do end up generating a C++ constant.
Right now, when we generate bindings for Java class A, and we encounter
a Java type B, we generate a corresponding C++ name only if A == B,
otherwise we generate a generic "jni::Object" C++ name. For example,
class Foo {
class Bar {
Foo getFoo(Bar bar);
}
}
In C++, Foo.Bar.getFoo would become,
class Foo {
class Bar {
jni::Object::LocalRef getFoo(Bar::Param bar);
};
};
This patch extends the code generator so that any Java class in the
chain of declared classes gets a corresponding C++ name. The above
example now becomes,
class Foo {
class Bar {
Foo::LocalRef getFoo(Bar::Param bar);
};
};
The flags added in toolkit/locales/Makefile.in turn out not to be actually
used, so just remove that.
The remaining uses of XULPPFLAGS are to set debug flags depending on whether
MOZ_DEBUG is set or not. Just set a dedicated variable with the right value
from configure.
The order in which backends appear is important, and dealing with deduplication
in configure.in is not really nice, so for all simplification purposes, this relies
on using AC_SUBST_SET, which does the deduplication and keeps the original order
in which items appear (despite its name).
While the name AC_SUBST_SET suggests the underlying type would be a set, it does
not actually matter that much in moz.build, and is not used that much anyways.
Right now, --with-android-sdk expects a path to a specific Android SDK
version, like /path/to/platforms/android-22. That path is exposed as
ANDROID_SDK; the Android SDK root is exposed as ANDROID_SDK_ROOT.
Right now, the provided platform's version number is extracted into
ANDROID_TARGET_SDK. The extracted ANDROID_TARGET_SDK is checked
against a minimum version number (supplied as a parameter to
MOZ_ANDROID_SDK).
After this patch, --with-android-sdk expects what is now
ANDROID_SDK_ROOT, and then derives ANDROID_SDK from that path and a
pinned SDK platform version number. The exact version number which we
search for is now a parameter given to MOZ_ANDROID_SDK. We accept and
fail, with a helpful message, if we recognize an old-style ANDROID_SDK
path.
The existing MOZ_ANDROID_{MIN,MAX}_SDK_VERSION variables remain as
they are.
Right now, the Android build tools are searched in a deterministic but
non-obvious manner. After this patch, the exact build tools version
number is now a parameter given to MOZ_ANDROID_SDK.
--HG--
extra : commitid : 7z4T3EYH8fg
extra : rebase_source : 118a2a163d0deb1896e4959f12e9fbb132732bd8
extra : histedit_source : f18feda343e3c8e9f0dbb65eb7127262690e3cad
This stops exposing ANDROID_BUILD_TOOLS and ANDROID_PLATFORM_TOOLS via
AC_SUBST. We expose most tools already, and this adds EMULATOR, and
consumes it (and ADB) where appropriate.
--HG--
extra : commitid : 9u0pibgE00
extra : rebase_source : 04e420c53d1d75ab8f055436d7dd69e148168c67
extra : histedit_source : a930a34f4dda44ee91b52caf68e02877b0502f01
This merely groups the AAR searches in the configure output, which
reads a little easier.
--HG--
extra : commitid : 8yoM0J2NNOq
extra : rebase_source : 989bf064ca0f2d4e0126726dad7529a218e11e62
extra : histedit_source : f8c211e64741b4558b185bfbf5523b67cc428232
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
--HG--
extra : commitid : 25Ft0BFs88O
extra : rebase_source : 05e3d1da8d42fa89d06ef48baee17bb77df5bd59
extra : histedit_source : 95b82309aca15c5a3c5f5a0eafbdcf75c5e8dfc0
We build gcc after clang, and extract libgcc libraries and libstdc++
headers from gcc and place them in the clang installation directory in a
way that clang favors before it searches the system for libraries and
includes.
This extracts the most useful browser-related measurements from rapl and
powermetrics.
--HG--
extra : rebase_source : 81ce14acc6c6e1bc7ac6c34bf119d8e619956dd1
This patch migrates moz_non_memmovable into the CustomTypeAnnotation
framework; bonus side-effects are more helpful error messages and less
code duplication.
Its only purpose is to disable PGO. Where that was not already explicitly done,
or irrelevant (because the directory only contains python), I disabled it in
moz.build.
As part of this move, HOST_NSPR_MDCPUCFG needed to be changed to get the quoting right.
--HG--
extra : commitid : J26MhSiPq9g
extra : rebase_source : 81c5b98371042803741ddace8d01b0097757dff3
This included adding the slugid 1.0.6 python source code in /python since slugid
is now a dependency of the ./mach taskcluster-graph command, as well us updating
references that used it. Previously the implementation was in-tree.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
This paves the way for defining additional Android packages in
moz.build, which is a step toward moving the special
mobile/android/base/Makefile.in aapt invocations into the generic
java-build.mk framework.
The new variables are both passthru variables for now: in the future,
we'll roll them into some aggregate Android APK definition.
It's worth noting that references to the variables in Makefile.in
files are only defined after including rules.mk (and thereby
backend.mk). This only required a few changes in the tree but it
confused me for some time.
--HG--
extra : commitid : G5mEvm8Ng4F
extra : rebase_source : 7ba05f2e53554549ffb5cefe270925e3e2025b6a
extra : histedit_source : eacd22f4b7edddab67147c413fea45a3ba292c0c
GeneratedJNIWrappers.h was updated in bug 1192079 to use inherited
constructors, which is a gcc 4.8 feature. Many people are still using an
older version of NDK which only comes with gcc 4.7.
To reduce verbosity of the generated code, this patch makes the code
generator use unqualified names when possible, e.g. use State::Ref
instead of GeckoThread::State::Ref. To accomplish that, function
prototypes now use the C++11 -> syntax for return types.
Currently, when we generate JNI wrapper for an inner class, the
resulting C++ class will not actually be a nested class of the enclosing
class. As a result, the class can be confusing to use. For example,
wrapping Java class GeckoThread.State results in two unrelated C++
classes, GeckoThread and State, and it'd be confusing to use State by
itself.
This patch adds support for inner classes. We start by scanning only for
top-level classes, and when processing each top-level class, we
recursively scan for inner classes through
JarClassIterator.getInnerClasses() and CodeGenerator.generateClasses().
For each Java inner classes, the resulting C++ class will be a nested
class. For example, wrapping GeckoThread.State will produce
widget::GeckoThread and widget::GeckoThread::State.
We have had singular ANDROID_ASSETS_DIR in Makefile.in for a while.
Fennec itself does not use the existing Makefile.in Android code, for
complicated historical reasons.
This makes the existing variable moz.build-only; generalizes the
existing variable to an ordered list; and adds the equivalent use of
the new list to the Fennec build, with a simple example asset.
This patch also updates the packager to include assets packed into the
gecko.ap_. Without the packager change, the assets/ directory in the
ap_ gets left out of the final apk. This whole approach is totally
non-standard but is more or less required to support our single-locale
repack scheme.
--HG--
extra : commitid : 4EAh1UNGNWT
extra : rebase_source : 5e5b4c4a120c3b4cc776c9f9380ddd2f9b63587e
extra : source : 0ddce3eb833e6d6180a19928a9b45d5d12f1d7fa
The PR was fixed in early 2011. clang 3.3, the oldest version of clang
that we build with, was released in mid-2013. It's safe to say that all
versions of clang now have this fix, and we can delete the check.
The way UPLOAD_EXTRA_FILES is currently exported makes the files added
to the list added in each directory that is being traversed recursively
because of the += in .mozconfig.mk, combined with "export".
The easy way out is to remove the export altogether, but being unsure of
the side effects of putting all non exported mk_add_options variables
in .mozconfig.mk, limit this to UPLOAD_EXTRA_FILES.
When switching between Gtk+3 and Gtk+2, config.cache will contain a PKG_CONFIG
that may not be suitable for the build:
- after a Gtk+2 build, config.cache will point to the system pkg-config, which
doesn't like the pkg-config files in the Gtk+3 tooltool package.
- after a Gtk+3 build, config.cache will point to the Gtk+3 tooltool package's
pkg-config, which is likely not there in a Gtk+2 build.
Setting PKG_CONFIG avoids all config.cache considerations altogether, so set it
appropriately for both cases.
LeanSanitizer reports two kinds of leaks: direct and indirect. A
leaked block that is pointed to by another leaked block is an
"indirect leak", while one that isn't is a "direct leak". Often,
indirect leaks are just things entrained by the "real" leak, but if
two leaked blocks are in a cycle, then they both end up being
indirect, so we need to report them, too.
This patch makes it so that indirect LSan leaks are treated the same
as direct leaks by Mochitests, which means they will turn the tree
orange. There are a few existing indirect leaks of various severity,
so I had add some suppressions. See those bugs for more details.
--HG--
extra : rebase_source : 0269666f546b6e349bebf216771fc6dfa4d9487a
This also completely remove build/automationutils.py.
--HG--
extra : commitid : 50v6EAQNEHV
extra : rebase_source : 4ac1347d73498f068979514c6afb16ac50ab4033
The API version detection functionality was broken in SDKProcessor
because we were passing in "Lpackage/Class;" as the class name rather
than just "package/Class". Also, some classes have a weird situation
where some methods were moved around in later API versions. For example,
some put* and get* methods in Bundle were moved to BaseBundle in API 21.
If we only checked BaseBundle.put*, we would think they are API 21+
only. The workaround is to check both the top-level class and the
declaring class for a member, and choose the lower API level as the
minimal API level for that member.
This patch also fixes bugs in including the right class members.
For SDKProcessor we want to include all public members of a class,
including inherited members, because the private/protected members are
not part of the public API. For AnnotationProcessor, we want to include
all the members declared in that class, including private and
protected members, because we may want to access private/protected
members of our own Java classes from C++.
Trying to decipher MOZ_SUBCONFIGURE_ICU given its lack of indentation is
difficult at best. It looks like some lines have tabs, and those tabs
make everything line up right...convert everything to spaces to make
sure things line up correctly.
Some mozconfigs don't include mozconfig.linux*, and don't get gtk-related
definitions, so move them in a separate mozconfig. To avoid having two
files, one for 32-bit builds and one for 64-bit builds, rely on the
includer to set PKG_CONFIG_LIBDIR appropriately.
At the same time, move all the --enable-default-toolkit=cairo-gtk2 in that
new file in the case the gtk3 package wasn't pulled from tooltool.
There are a variety of ways that the parent and child process ensure that
the child process exits quickly in opt builds, but for AddressSanitizer
builds we want to let the child process to run to completion, so that we
can get a LeakSanitizer report.
This requires adding some addition LSan suppressions, because running
LSan in child processes detects some new leaks.
This will add more verbosity, with the intent of having the triggered
suppressions be displayed in the form:
"--23983-- used_suppression: 3 Bug 794372 /builds/slave/try-l64-valgrind-0000000000000/src/build/valgrind/cross-architecture.sup:90 suppressed: 20,736 bytes in 648 blocks"
It's been clear from user feedback that people don't realize that `mach
mercurial-setup` doesn't make any changes unless they tell it to.
Reinforce this message in the prompts printed by mach_boostrap.py.
--HG--
extra : commitid : DmE2U8DHQ3M
extra : rebase_source : 20e5c4d6ff7610bdceef7817c5ea2854d271ccdf
Add a mozconfig fragment enabling rust on mac builds.
Include it in the official integration mozconfig files only.
Developer checkouts don't require rust.
This command is used by tab completion handlers. A user reported that
hitting tab in his shell resulted in the mercurial-setup out of date
check spewing output.
--HG--
extra : commitid : 5DE199lHcn2
extra : rebase_source : 7f2ef1c325b3f0deb091798a5d21820257d6c1f6
extra : amend_source : 016428cf3d2442cc2ced24d328aec53a752619ab
Having not configured or out-of-date tools benefits nobody. It slows
people down.
Version control tools are an integral part of working on Firefox. It is
important for version control tools to be configured optimally and to be
continuously updated so they stay optimal.
The `mach mercurial-setup` command exists to optimally configure
Mercurial for working on Firefox and other Mozilla projects.
This commit adds a pre-dispatch handler to mach that will verify
Mercurial is in a happy state. If `mach mercurial-setup` has never
executed, it will complain. If `mach mercurial-setup` hasn't been
executed in the past 31 days, it will complain.
Yes, aborting command execution and forcing people to context switch to
run `mach mercurial-setup` is annoying. First, we have carved out
several exceptions to this behavior, including detection for running in
automation, on the machines of curmudgeons, when Mercurial isn't being
used, and from non-interactive processes. Second, I argue that people
ignore optional notifications and that having persistently
poorly-configured tools is worse than a single context switch at most
every month. Therefore, the heavyhanded approach is justified.
In addition, if we did support a non-fatal notification, we would
introduce the problem of extra output from commands. If anyone was e.g.
parsing mach output, we could very likely break those systems. These
cases should be caught by the isatty() check or be running in a context
with MOZ_AUTOMATION set. But you never know.
--HG--
extra : commitid : 7f7JQpa953u
extra : rebase_source : 47b6304b6ac2c9d8136f2023a7d03df7d1f45e4f
extra : source : f06616ee7b2b54d63d20ee4795539514d1df8c7b
Having not configured or out-of-date tools benefits nobody. It slows
people down.
Version control tools are an integral part of working on Firefox. It is
important for version control tools to be configured optimally and to be
continuously updated so they stay optimal.
The `mach mercurial-setup` command exists to optimally configure
Mercurial for working on Firefox and other Mozilla projects.
This commit adds a pre-dispatch handler to mach that will verify
Mercurial is in a happy state. If `mach mercurial-setup` has never
executed, it will complain. If `mach mercurial-setup` hasn't been
executed in the past 2 weeks, it will complain.
Yes, aborting command execution and forcing people to context switch to
run `mach mercurial-setup` is annoying. First, we have carved out
several exceptions to this behavior, including detection for running in
automation, on the machines of curmudgeons, when Mercurial isn't being
used, and from non-interactive processes. Second, I argue that people
ignore optional notifications and that having persistently
poorly-configured tools is worse than a single context switch at most
every 2 weeks. Therefore, the heavyhanded approach is justified.
In addition, if we did support a non-fatal notification, we would
introduce the problem of extra output from commands. If anyone was e.g.
parsing mach output, we could very likely break those systems. These
cases should be caught by the isatty() check or be running in a context
with MOZ_AUTOMATION set. But you never know.
--HG--
extra : commitid : AWLag0bpQOY
extra : rebase_source : fba19b918e9eadc6d5976c10d82974fb7e835e9d
A subsequent commit will want to access the state directory path without
possibly creating it. Make that possible by extracting path resolution
to its own function.
--HG--
extra : commitid : 60aMbblXNF9
extra : rebase_source : 5e83e36d32ff1f581e91b442005139c89f3bc3f3
- Removed old robotium jar in replace for the newer one.
- Newer robotium has packaging changes which were updated in all tests.
- Updated in build.gradle and makefile.
--HG--
extra : transplant_source : %949%F2%F6%10v%9A%CA%8B%FD%EE%05%28%D8%1E%0D%09_%BE%D3
isatty() raises ValueError if the file descriptor is closed. Detect
closed file descriptors.
--HG--
extra : commitid : 3wH6lYWoPHZ
extra : rebase_source : df0f657a3b2afa6dbc710e98c0b3c31f3b8be486
extra : amend_source : 7a153ea95c7b77cf0d53116d70c7a840fbbdb92e
We were de-referencing the checker variable after having moved it into
the array, which was causing a null pointer crash.
With this fixed, the plugin can be built with more recent versions of
clang.
Backed out changeset 58331e57de1c (bug 917999)
Backed out changeset 50f9123412c7 (bug 917999)
Backed out changeset 3b19643ec039 (bug 917999)
CLOSED TREE
Write a mozconfig fragment which makes the rust toolchain
provided by tooltool available for linux builds.
Use linux64 mozconfigs to enable rust for official builds of
that target. These aren't used outside of automation builds,
so including rust there will verify code on check-in without
requiring developers to install rust.
This removes ambiguity as to which modules are being imported, making
import slightly faster as Python doesn't need to test so many
directories for file presence.
All files should already be using absolute imports because mach command
modules aren't imported to the package they belong to: they instead
belong to the "mach" package. So relative imports shouldn't have been
used.
--HG--
extra : commitid : 6tFME1KKfTD
extra : rebase_source : 78728f82f5487281620e00c2a8004cd5e1968087
