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
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
yasm doesn't support aarch64, and trying to use GNU as with an MSVC
build seems like sadness waiting to happen. Instead, we'll generate our
own assembly file that armasm64 will accept.
The files into APK isn't extracted on our Android build, so it isn' good to use data file on Android build.
MozReview-Commit-ID: 4AQb2b7ScAH
--HG--
extra : rebase_source : 02d493f9b0f6dad5c5106ea45863f2f7c9c0b97e
Also fixes bug 926980 - load ICU data from an archive file.
Stop invoking ICU's autoconf build system. Instead, have hand-authored
moz.build files under config/external/icu to build what we need. In addition,
we'll commit a pre-built copy of the ICU data file (currently icudt56l.dat)
under config/external/icu/data to avoid having to build ICU host tools to
generate it. config/external/icu/data also contains some assembly files
which can generate an object file containing the ICU data file contents
so that the JS shell (or standalone JS builds) can be linked directly to
the data without having to deal with the external data file. This requires
yasm or GNU as.
Various bits of packaging have been updated to account for the ICU data file.
XPCOM initialization now sets the ICU data directory so ICU can locate its
data file.
The update-icu.sh script has been modified to read the list of C/C++ source
files out of the ICU Makefiles and update `sources.mozbuild` files under
config/external/icu, as well as build a local copy of ICU using its
autoconf build system to generate the ICU data file to be committed in-tree.
MozReview-Commit-ID: 8Pfkzqt6S1W
--HG--
extra : rebase_source : 31426cddddb5543e0191059ba2f2eb069abe7727
Now that MOZ_BUILD_APP is set to js when building js/src, we can
distinguish those builds with MOZ_BUILD_APP==js instead of BUILDING_JS.
Consequently, remove BUILDING_JS.
Now that MOZ_BUILD_APP is set to js when building js/src, we can
distinguish those builds with MOZ_BUILD_APP==js instead of BUILDING_JS.
Consequently, remove BUILDING_JS.
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.
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.
