Artifact builds can't rely on variables such as MSVC_C_RUNTIME_DLL when
packaging because they haven't run the parts of configure that sets
them. Existing references to these variables in package-manifest.in
are causing us to package entire directories we shouldn't when these
variables are empty. This commit prevents us from relying on these
variables when packaging an artifact build.
MozReview-Commit-ID: 48jOsdvpoxJ
--HG--
extra : rebase_source : 64a1a97c9aa51bb4bd7b020c4a7e1bdea239872f
Update also the similar logic in browser/installer/package-manifest.in. The
reason I added the symbolizer is because it'd be useful when someone conduct
jsshell testing/fuzzing.
MozReview-Commit-ID: J9IqFWsnskS
--HG--
extra : rebase_source : db461065f778fc025576b1fc7612642181d94dcd
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
In bug 922912, we folded back gkmedias.dll info xul.dll, so in practice, there
is no default configuration left that exercises GKMEDIAS_SHARED_LIBRARY. And
sure enough, it's been broken for months in many different ways.
The gkmedias intermediate library is however kept for webrtc signaling tests.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
packager.py itself has been able to do preprocessing since the beginning.
For some reason, Makefile.in-driven preprocessing was kept back then, and
never was removed, and even worse, concatenation was added on top of it.
There is however a downside to the current way of doing things: error
reporting is given relative to the given manifest, which in the current
case is the preprocessed/concatenated file, so line numbers don't match
what is in the file in the source tree. However, when packager.py does
preprocessing itself, line numbers are reported properly.
Thus, switch all package manifests to packager.py-driven preprocessing.
This is necessary for plugins when building libxul for GTK+ 3
because libxul will link against GTK+ 3 and some plugins link
against GTK+ 2, but both GTK+ libraries can't be loaded in the
same process. With this change, we have an indirection between
libxul and libgtk, named libmozgtk. plugin-container will
be modified to load libmozgtk2 in order to only have GTK+ 2
in its address space, thus enabling various plugins (e.g. flash)
on GTK+ 3 firefox.
Chris Manchester
Ting-Yu Chou
Bob Owen
Benjamin Smedberg
Masatoshi Kimura
Chris AtLee
Nicholas Nethercote
George Wright
Ted Mielczarek
Mike Hommey
Birunthan Mohanathas
Kit Cambridge
Steven Michaud
Ryan VanderMeulen
Jacek Caban
Brian Smith
Stephen Pohl
Carsten "Tomcat" Book
Nomis101
Ehsan Akhgari
Nathan Froyd
Jim Blandy
Emilio Pozuelo Monfort
Alexandre Poirot