To avoid sending identifying information, common absolute paths are patched with placeholder values. For example, devs
may place their Firefox repository within their home dir, so absolute paths are doctored to be prefixed with
"<topsrcdir"> instead.
Additionally, any paths including the user's home directory are patched to instead be a relate path from "~".
Differential Revision: https://phabricator.services.mozilla.com/D78962
Rather than always printing instructions at the end of the bootstrap phase, we will now create a mozconfig
file if one doesn't exist and there's configuration to be written.
Differential Revision: https://phabricator.services.mozilla.com/D78417
For standalone JS builds there are three possibilities: no-NSPR (the default),
build NSPR, or use system NSPR.
This patch makes no-NSPR the default again when not overridden by --enable-nspr-build
or --with-system-nspr. This was likely regressed by bug 1641775.
Differential Revision: https://phabricator.services.mozilla.com/D78001
clang_getAddressSpace was found as a clang 5.0+ API by comparing the "tools/libclang/libclang.exports" files in the clang source code.
"clang_getAddressSpace" exists for 5.0.0 and 10.0.0, but not for 4.0.1.
Differential Revision: https://phabricator.services.mozilla.com/D78374
When not using --with-android-ndk, NDK root is `~/.mozbuild/android-ndk-r20`.
When building this NDK path, since we use `os.path.join`, so it may include "\"
as file separator on Windows host. Then some options such as `-gcc-toolchain`
become invalid path (ex. `C:/users/makoto.mozbuildandroid-ndk-r20/`..).
So we should replace file separator with "/".
Differential Revision: https://phabricator.services.mozilla.com/D77820
When running |mach python| with python 3, it was failing when importing "enum", since it would get the python 2 backport. By making these packages only
available to python 2, we allow python 3 to import standard library packages properly.
Differential Revision: https://phabricator.services.mozilla.com/D77960
Version of NSS >= 3.27 have a pkg-config file. We're now requiring 3.53,
so while moving, just use pkg-config, which is simpler.
The old-configure check that rejected some untested platforms for
in-tree NSS is actually rejecting none: the accepted platforms cover all
the supported ones, so we remove that check.
And because building with system NSS without system NSPR doesn't make
sense, imply the latter when the former is used.
Differential Revision: https://phabricator.services.mozilla.com/D77428
At the same time, because it's now simpler to do so, set the right data
file name for big-endians, even though we don't have or produce it
(bug #1264836). Also remove USE_ICU, which is redundant with
JS_HAS_INTL_API, and actively break the build at configure time when
using --without-intl-api with Firefox because this hasn't actually
worked for close to 3 years (since bug 1402048).
Differential Revision: https://phabricator.services.mozilla.com/D77416
Versions of NSPR >= 4.10 come with a pkg-config file. We currently
depend on 4.9.2 for spidermonkey, but much more recent versions for
Firefox. 4.10 is less than a year newer than 4.9.2, and 4.10 is 7 years
old, so bumping the requirement to 4.10 is not really a big deal.
With the use of pkg-config, --with-nspr-cflags and --with-nspr-libs are
not needed.
None of the AC_TRY_COMPILE tests were any useful because
PR_STATIC_ASSERT and PR_UINT64 have been when we look for them since
4.8.6 and 4.9 respectively.
Differential Revision: https://phabricator.services.mozilla.com/D77412
As all versions of zlib >= 1.2.3.1 have a pkg-config file, and 1.2.3.1
is close to 14 years old, let's drop 1.2.3 and just use pkg-config, which
simplifies what we need to do dramatically.
Differential Revision: https://phabricator.services.mozilla.com/D77404
l10n-merge creates a full merge dir for a while now, let's
simplify the build logic to only read from that directory
during repacks and langpacks.
Differential Revision: https://phabricator.services.mozilla.com/D77023
Instead of doing this:
a) read existing file into memory
b) append new entries
c) sort all entries
d) write unique entries back to file
We now do this:
a) sort new entries
b) loop through existing file entries, one at a time, writing them to a tmp file
c) insert the new entries in between the existing file entries in lexicographic order,
and deduplicating the new entries
d) write any remaining new entries (that are lexicographically after the last
entry in the pre-existing file), again deduplicating the entries
e) move tmp file back to original file location
This avoids reading the entire file into memory which could be potentially
hundreds of MB large.
The changes in FileOperations.* are needed to support these changes, as we now
have two files that we're dealing with - reading from one and writing to the
other. We still use a Mutex (Windows) or exclusive-flock (POSIX) on the file
for the duration of the entire operation, so we should still be robust in the
face of multiple concurrently running clang processes.
Differential Revision: https://phabricator.services.mozilla.com/D76202
The configure sandbox has a list of arguments to handle, and removes
each of them when it resolves the corresponding options through e.g. a
`@depends`. When the configure sandbox is finished, what's supposed to
be left is unknown options.
The mozconfig injections adds elements to that list of arguments to
handle. The problem is that by the time the mozconfig injection happens,
some early options have already been handled by the sandbox and won't be
re-handled. Which means by the end of configure, the arguments are still
there, and the sandbox throws an error because it thinks they are for
unknown options.
Things were actually working before bug 1264527, essentially because we
had an explicit list of mozconfig variables that would be injected, and
that didn't include those early options.
So what we now do is to not actually inject those early options from
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D76276
