I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
The files are copied verbatim from upstream autoconf 2.13 (but only the
files we need) and old.configure is adapted to use the vendored version.
Differential Revision: https://phabricator.services.mozilla.com/D89554
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
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
iOS support for Gecko has not been tested in years and is most probably
out of date. The build system part of it, specifically the checks in
build/autoconf/ios.m4, are not trivial to port to python configure, and
they prevent other things from moving to python configure (because some
of them change value when MOZ_IOS is set).
The code is left alone, although it could probably be stripped off as
well, but I'll leave that as an exercise for someone else.
Differential Revision: https://phabricator.services.mozilla.com/D75463
This patch will support all of `-std:`, `-std=`, and `-Xclang -std=`.
This patch will also a bit faster because the current code will call `sed` for
each argument.
Differential Revision: https://phabricator.services.mozilla.com/D63472
--HG--
extra : moz-landing-system : lando
clang-plugin.dll links against clang.exe so they both need to use the same C++ standard. This is achieved by having build/clang-plugin/moz.build use the flags from llvm-config. However, llvm-config uses the `-std:c++14` format, so our flags end up looking like:
`-Xclang -std=c++17 ... -std:c++14`
and apparently the former wins out in clang's option plumbing, so the compiler still thinks we requested c++17.
This patch makes clang-plugin use the `-Xclang -std=` format so that the override happens as desired.
Differential Revision: https://phabricator.services.mozilla.com/D62271
--HG--
extra : moz-landing-system : lando
JSAPI functions are not extern "C" anymore. This warning has a couple false
positives due to template specialization (see first patch of this bug), but we
were already working around them, because apparently some mingw builds use it.
Once I fix cbindgen to generate the specializations as needed we can remove
those workarounds, but this is green in the meantime and doesn't hurt.
Depends on D61626
Differential Revision: https://phabricator.services.mozilla.com/D61627
--HG--
extra : moz-landing-system : lando
Whether ENABLE_INTL_API and ENABLE_TYPED_OBJECTS are defined, affects
the behaviour of JS_FOR_PROTOTYPES for the prototypes of Intl and
TypedObject. Therefore, these macros have to be available to embedders.
Rename them to JS_HAS_INTL_API and JS_HAS_TYPED_OBJECTS (in line with
the existing JS_HAS_CTYPES) everywhere they are used, and add them to
js-config.h.in.
Differential Revision: https://phabricator.services.mozilla.com/D52461
--HG--
extra : moz-landing-system : lando
Whether ENABLE_INTL_API and ENABLE_TYPED_OBJECTS are defined, affects
the behaviour of JS_FOR_PROTOTYPES for the prototypes of Intl and
TypedObject. Therefore, these macros have to be available to embedders.
Rename them to JS_HAS_INTL_API and JS_HAS_TYPED_OBJECTS (in line with
the existing JS_HAS_CTYPES) everywhere they are used, and add them to
js-config.h.in.
Differential Revision: https://phabricator.services.mozilla.com/D52461
--HG--
extra : moz-landing-system : lando
This is just drive-by, but it confused me. We require at least clang 4 to build
nowadays.
Differential Revision: https://phabricator.services.mozilla.com/D50646
--HG--
extra : moz-landing-system : lando
There are about the same number of occurrences of "ENABLE_INTL_API" and "EXPOSE_INTL_API"
in the tree, so preferring one over the other doesn't lead to fewer changes. Therefore
I went with "ENABLE_INTL_API", because "ENABLE_" (resp. "MOZ_ENABLE") is already used as
the prefix for other preprocessor ifdef's.
Differential Revision: https://phabricator.services.mozilla.com/D41188
--HG--
extra : moz-landing-system : lando
- Part 3 uses functions added in ICU 64, so we need to bump the version requirement.
- Also remove a version check which is now true be default.
Differential Revision: https://phabricator.services.mozilla.com/D26717
--HG--
extra : moz-landing-system : lando
- Part 3 uses functions added in ICU 64, so we need to bump the version requirement.
- Also remove a version check which is now true be default.
Differential Revision: https://phabricator.services.mozilla.com/D26717
--HG--
extra : moz-landing-system : lando
We've been relying on frame pointers being indirectly enabled via things
like --enable-profiling for some time, but this doesn't scale because
some things may want frame pointers while wanting --disable-profiling.
So we move MOZ_FRAMEPTR_FLAGS to python configure and add a new option
to decide whether to enable frame pointers or not.
Differential Revision: https://phabricator.services.mozilla.com/D34117
--HG--
extra : moz-landing-system : lando
Stand-alone JS builds now default to without-NSPR on all platforms.
Note that the JS shell builds we do in automation pass --enable-nspr-build so they shouldn't be affected by
the JS shell changes.
Differential Revision: https://phabricator.services.mozilla.com/D33933
--HG--
extra : moz-landing-system : lando
Interestingly, the change makes one configure test have a different
result (localeconv ends up being found when it used not to be found),
but the result of that check is actually not used on Windows because we
set HAVE_LOCALECONV manually.
Differential Revision: https://phabricator.services.mozilla.com/D25902
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando