The deletions in xptcall are when we don't even have support for the CPU
in moz.configure, so I assume that people haven't been compiling on
those architectures for quite some time.
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
This is basically just this: https://bugs.chromium.org/p/chromium/issues/detail?id=562951
The original profile that caused us to add this check has bigger problems than negative
colorant tristiumlus values. We should reject it using a better metric. In the mean time
let's not reject these things on macOS.
Currently, the build scripts enable AltiVec unconditionally on all ppc*
targets. However, there some ppc* targets which do not support AltiVec
instruction set extensions, these are often embedded systems like the
PowerPC e500 or similar which have their own type of instruction set
extensions like SPE. Trying to enable Altivec support on these targets
results in a compiler error, hence we need to add an autoconf test for
AltiVec support before trying to enable it on ppc* targets.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
--HG--
extra : rebase_source : 6c4df813d97d95046fd2269c876313ce7591c5cf
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This patch fixes various warnings from MSVC.
- Several "truncation from 'double' to 'float'" warnings, easily fixed by
appending 'f' to literals.
- Some "signed/unsigned mismatch" warnings. In read_tag_lutType(), MSVC is
apparently promoting the multiplication of a uint8_t and a uint16_t to an
int32_t, oddly enough. A uint32_t cast fixes the warning.
- |offset| was unused in qcms_data_create_rbg_with_gamma().
- A couple of "overflow in floating-point constant arithmetic" warnings
involving INFINITY in transform_util.c. There is some type confusion here --
in C99 HUGE_VAL is a double and INFINITY is a float. So the HUGE_VAL here
should actualy be HUGE_VALF. But, strangely enough, that isn't enough to
avoid the warning, I don't know why. However, it turns out that any
non-positive value for |interval| will have the same effect, so I just
removed all the INFINITY/HUGE_VAL stuff and used -1 instead.
It also fixes an ARM-only GCC warning.
- "'__force_align_arg_pointer__' attribute directive ignored". This is an
x86-only attribute. Instead of disabling it on x86-64, instead enable it on
i386 (which avoids enabling it uselessly on ARM).
--HG--
extra : rebase_source : 61015b7e48aebd58035fc222abf076e79a99a972
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
What LIBXUL_LIBRARY does is:
- Imply FORCE_STATIC_LIB
- Build with -DIMPL_LIBXUL
- Build with -DMOZILLA_INTERNAL_API
Those intermediate libs that end up in gkmedias and have LIBXUL_LIBRARY defined
in their moz.build are all third party code (or handled like third party code).
Besides FORCE_STATIC_LIB, none of the side effects of LIBXUL_LIBRARY should be
needed.
Thomas P.
Nathan Froyd
Nicolas Silva
Ryan VanderMeulen
Milan Sreckovic
Lee Salzman
Sylvestre Ledru
Jeff Muizelaar
John Paul Adrian Glaubitz
Miko Mynttinen
Tom Tromey
Mike Hommey
Nicholas Nethercote
Benoit Girard
David Major
Seth Fowler
Shashank Sabniveesu
Ms2ger
Ehsan Akhgari
Masatoshi Kimura
guozhu cheng