The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
I tested locally that both checks give the expected error if I
temporarily change the != to an =.
--HG--
extra : transplant_source : %01N%B9%8B%BC%1E%07%D6%AE%BA2%7B%87%FB%25Y%19%B6%A9%D3
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
--HG--
extra : transplant_source : D%D3%FE%169%05%D0X%F3KK%17%9EW%88%BCs%9B%86%5D
It looks like overwriting AS here is not intentional. Before this patch,
it is impossible to override AS through mozconfig for anything that runs
past this stage in configure.
Some Android SDK installations do not have the zipalign program in
the same directory as other Android build tools. For example,
zipalign may be found in /build-tools/21.1.2 whereas the
rest of the build tools are in /build-tools/android-4.4.
Right now, if the LLVMCONFIG variable is not set in the .mozconfig, we
first look for the system default llvm-config and only then we ask clang
itself, which breaks building with the clang plugin if you make $CC and
$CXX point to a non-default clang binary. This patch fixes the issue
by reversing the search order.
--HG--
extra : rebase_source : 23ab716f4e220097e4c31092475dba769f4e7dfc
In certain configurations, in particular when installing the Android SDK
using HomeBrew, one sees a configuration with symlinks like:
[brian@brian-macbook git]$ ls -l /usr/local/Cellar/android-sdk/23.0.2/
total 72
...
lrwxr-xr-x 1 brian admin 38 Nov 14 16:39 platforms -> ../../../var/lib/android-sdk/platforms
...
drwxr-xr-x 26 brian admin 884 Nov 14 17:43 tools
In this case, we have
ANDROID_SDK=/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21.
It is an anti-pattern to use ANDORID_SDK/.. to find other paths in the
tree. This pattern is used in at least two places:
1) When we try to find
/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21/../../tools,
we end up in the /usr/local/var/lib subtree. This patch works around
that by exporting and using ANDROID_TOOLS; ANDROID_TOOLS itself is
extracted using path matching, rather than following .. through the
filesystem.
2) We also need to use ANDROID_SDK_ROOT rather than
ANDROID_SDK/../.. through-out.
--HG--
extra : rebase_source : 5e0323a94f2b80550f17a624e16f338cdeec406d
On automation, this brings Windows configure time on a clobber from 5:30 to 3:10.
Sadly, because make needs to run under intl/icu/host before configuring
intl/icu/target, intl/icu/host needs to be configured independently. Fortunately,
that's not configured for normal windows builds anyways.
Also, having multiple subconfigures sharing the same cache file is dangerously
racy. Fortunately, not a lot do. In fact, only js/src and $_subconfigure_subdir
do, so force the latter (only used for ldap sdk on comm-central) not to
configure in parallel.
This saves dexing and shipping the Google Play Services and other Google
libraries, which add resources and about 3megs of code.
Due to ordering issues, the relevant flags and toggles were moved to
configure.in and exposed early enough to be used by confvars.sh.
While bug 903369 added some kind of wrapping, msys mangling on Windows made
it hard to make the python wrapper invoke subconfigures itself. This change
overcomes this, allowing to run subconfigures entirely independently of
the main configure if necessary, or to do more fancy checks without having
to resort to m4 and shell.
All subconfigures are essentially doing it already, so just inverse the process. That would also limit problems with additional subconfigures (all the recent ones had to come with their own config.cache)
This adds a format option to mach environment and uses it in client.mk to
create a .mozconfig.json in the objdir, containing all the relevant data
from mozconfig. If the mozconfig doesn't change in a way that alters that
data, we still skip configure.
At the same time, use mach environment in place of mozconfig2configure and
mozconfig2client-mk, which makes us now have only one mozconfig reader.
Also, in the mozconfig reader, keep track of environment variables (as
opposed to shell variables), so that changes such as a variable that was
exported not being exported anymore is spotted. At the opposite, in order
for irrelevant environment variable changes not to incur in re-running
configure, only a set of environment variables are stored when they are
unmodified. Otherwise, changes such as using a different terminal window,
or even rebooting, would trigger reconfigures.
Finally, make mach environment emit both MOZ_OBJDIR and OBJDIR for
client.mk, and cleanup some objdir-related things in client.mk..
At the same time, make the mozconfig reader take MOZ_OBJDIR from the
environment if it is defined there and not in the mozconfig.
CLOSED TREE (but for the commit above this because the commit hook only
appears to look at the tip commit)
--HG--
extra : rebase_source : c88e7e3f4d24dcd59a1a0b5577e3a77da68f3d08
extra : amend_source : 5be936181048b01850e9ef91c25fa0c7363d118d
This patch does two things: 1. Treat clang on Windows explicitly as MSVC. There
are some places in our build system where we try to detect clang by looking at
the output of $(CC) -v, and that will cause us to believe that we are using
clang, which is not helpful. This patch defines the CLANG_CL variable when it
detects clang being used on Windows. It also masquarades clang-cl as MSVC
2012, which is how the compiler introduces itself through the _MSC_VER
predefined variable.
2. Disable a bunch of things which currently are not supported on clang-cl. As
we proceed with this port, hopefully we'll be able to remove everything in this
list, but this will get us closer to be able to build with clang-cl.
With this patch and clang-cl trunk, we can get past the configure stage of the
build.
--HG--
extra : rebase_source : e5b8d77e4571c936820cec858953d58b6f31e0d5
