Because we have no linking configure test in python configure (yet), we
just make old-configure tests use LINKER_LDFLAGS, and make those flags
added to LDFLAGS by old-configure at the same time.
--HG--
extra : rebase_source : 80ab7c5021c7ddd1b53d58ef76cd4372a524d3cb
clang seems to have decided that a new warning,
-Wused-but-marked-unused, is useful. For the purposes of our codebase,
where we add __attribute__((unused)) explicitly to avoid warnings about
unused things, this new warning is useless. The new warning is also
quite noisy, given that we have unused things in commonly-used headers
like Assertions.h. So disable the warning.
MOZ_WIDGET_TOOLKIT can be used for platform choice for Gamepad. Need
to leave linux header check in configure for now.
MozReview-Commit-ID: VT7T2KmLts
--HG--
extra : rebase_source : 02e7a23311c65fccffb1375a3adf8980d3d6031c
Some configurations of SpiderMonkey wind up producing C++ switch statements of
the form
switch (..) {
default: break;
}
We hoped that they would simply be optimised out without comment. But MSVC
warns about the lack of non-default cases, which then are escalated into
errors, causing the build to fail. This commit simply disables that warning
feature when building with MSVC.
--HG--
extra : rebase_source : 468022d30cdaf483aaa64fc7aa9dd1308fbc7335
We use -O2 for js (because we can) and we use -O1 for the root because there is an x86 compiler bug
that is not immediately bypassable
MozReview-Commit-ID: CnDk2ko3jfo
--HG--
extra : rebase_source : bf889ab143bbf9480a261b06000d62cf0e1af8cc
-TC specifies 'treat all inputs at C files' which breaks things when you
specify a @list file of inputs.
During configure, -TP is required for C++ configure checks (although we
could probably make it smart and not need it at all), but -TC does not seem
to be required.
MozReview-Commit-ID: DNA8vUMdIXb
--HG--
extra : rebase_source : 523c6d815adf55c834fd858b10010123f86b25f6
MOZ_UPDATE_CHANNEL is meant to set the channel to use for the updater,
and nothing else. It's not an indicator of which branch we're building
on and it's not an indicator of whether it's a developer build or a CI
build. The latter seems to be what it's used for for A11Y_LOG, so use
DEVELOPER_OPTIONS instead.
--HG--
extra : rebase_source : 48822af1e4af444e00c89859c51c01c57d130248
This option does nothing if it's provided, and things will probably
break in some most peculiar manner if somebody uses --without-pthreads.
Given that neither outcome is useful, we should remove the option.
target value of Anndroid/arm is arm-unknown-linux-androideabi, so arm-*-linux*
matches on android/arm and MOZ_CRASHREPORTER is unset as default option.
Since taskcluster's build adds --enable-crashrepoter as default, we should set
it as developer's default too.
MozReview-Commit-ID: 8V6sWAN07F9
--HG--
extra : rebase_source : b4a26eea2d53eb8b53cc49e972d9d41b32d4ec97
We use a wrapper script when compiling with MSVC to parse the
/showIncludes output and thereby generate a Makefile dependency
fragment. This fragment enables us to do correct and faster incremental
builds. But the cost of invoking the wrapper script can be significant;
it's an extra process or two to launch for every single compilation.
Instead, let's have clang-cl generate the dependencies directly, which
should be somewhat faster.
That NDK bug has been fixed since r8c, and we now require something more
recent than that. This effectively reverts the changes from bug 720621
and bug 734832.
--HG--
extra : rebase_source : 9ff76a790ec4135dc0172cfd0f11fc1ecef7df64
The moz.build Java JAR definitions are, of course, broken, but they
will be removed soon enough.
MozReview-Commit-ID: KIxqLDwd9I7
--HG--
extra : rebase_source : 8312b3f125793f73d3e835d1c0a5c7cabd4ebc0c
CFBundleIdentifiers can only contain [A-Za-z.-], and by convention
the app component is lowercase and does not contain '.'.
Make configure delete all characters other than [a-z-] when generating
MOZ_MACBUNDLE_ID from MOZ_APP_DISPLAYNAME.
--HG--
extra : rebase_source : f80df747c0c0ed6dae1cd9f2dc0e916da911cf8b
This is ancient and the team that used it (gfx) is no longer using it.
MozReview-Commit-ID: HrDgmAU9QeW
--HG--
extra : rebase_source : c4a64965c4ae1a50888893e881a6e8a9688a58b6
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 22008e9333b15c594ce26c2a52f67396d6e3ab84
extra : source : f918500d9cf5112b70bc8e0a120df435b02252b7
It hasn't been used for a long while, and the screenshot tool is only
used for tests. So keeping the code essentially always disabled doesn't
have much value.
--HG--
extra : rebase_source : 6bf696d6543cbdd3ef66e19d4dc110134b761b63
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : 5547e2c8fbf4e2e87182b8720d8352c131e4ec65
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 38a9781c472d858f3300cbbcbdc6d2311c465713
After landing bug 1356263, no one uses HAVE_I18N_LC_MESSAGES. So it is
unnecessary to check LC_MESSAGES.
MozReview-Commit-ID: IPgl3rQ2qrd
--HG--
extra : rebase_source : 542ada2cf9ac2775855bba29f39044b55fa93f20
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 5a5730b4b9ce84af40a7c73c4f1abba017103f02
The OSX linker apparently decides on its own to link against system
frameworks. We end up with libxul linked to 6 frameworks that were never
given on the command line, and we do use symbols from those.
Interestingly, for those frameworks that don't appear on the command
line, there is no determinism in how stubs for lazy bindings (equivalent
to Linux's PLT, AIUI) are laid out in the binary. But for those that do
appear on the command line, the layout is deterministic.
So add those frameworks to the command line.
With this change, the remaining difference between two builds of the
same changeset on try is due to symbol tables for profiling. Stripping
those (like we do on beta/release) produces no differences.
--HG--
extra : rebase_source : 151342f3c0067c16c26e111247f6da58f4b639be
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
We need MOZ_UI_LOCALE even when building the JS shell so
config/config.mk variable assignments don't run into issues. But it
doesn't make any sense to configure a UI locale for the JS shell. So
make --enable-ui-locale a normal `option`, but give it a `default`,
which is the value shell-only builds will always see.
--HG--
extra : amend_source : 047759dd6ec446d9d6f8f5992ed9cf6628ce859e
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
We only had this "for flexibility with other platforms", but given that
we set it to the same thing for all platforms, and nobody has tried to
change that, this flexibility isn't actually needed.
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : f7582d7089f0f4582a02aeaef090dc0701df994d
It's no longer used, and won't be able to work with the removal of speech synth direct audio support.
MozReview-Commit-ID: BMdeRJHes0R
--HG--
extra : rebase_source : 9f45b360d27f8013ef229eba79e9d9921d0fdb26
It's no longer used, and won't be able to work with the removal of speech synth direct audio support.
MozReview-Commit-ID: BMdeRJHes0R
--HG--
extra : rebase_source : 9f45b360d27f8013ef229eba79e9d9921d0fdb26
This work around is required when using icecream distributed compilers. Icecream doesn't pass the original filename that would allow the remote clang to automatically determine the language type.
MozReview-Commit-ID: LMs022jDkPt
--HG--
extra : rebase_source : d3d43c29f0e2cf91a29677a1e827463f9e0a9f1d
Preserving the MOZ_MACBUNDLE_ID will avoid issue related to bundle identifier
MozReview-Commit-ID: IDIZGl6usXA
--HG--
extra : rebase_source : b01934cdf8a42d805ae467cc08b5beafb02c0732
We currently turn off the C++14 sized-deallocation facility on MSVC, and
we'd like to ensure we do the same thing for clang and gcc. To do so,
we add new functionality to moz.configure for checking and adding
compilation flags, similar to the facility for checking and adding
warning flags. The newly added facility is then used to add
-fno-sized-deallocation to the compilation flags, when the option is
supported.
Once we do this, we can't define the sized deallocation functions in
mozalloc.h; the compiler will complain that we are using
-fno-sized-deallocation, yet defining these special functions that we'll
never use. These functions were added for MinGW, where we needed to
compile with C++14 ahead of other platforms to be compatible with MSVC
headers. But they're no longer necessary, though they would be if we
removed -fno-sized-deallocation; the compiler will complain if we do
that and we'll add them back at that point.
C5038 is a new warning in VS2017, similar to gcc and clang's -Wreorder, which is enabled by -Wall. We should enable C5038 so Windows developers can see these warnings locally instead of when gcc and clang fail with warnings-as-errors on Try.
https://blogs.msdn.microsoft.com/vcblog/2017/07/21/diagnostic-improvements-in-vs2017-15-3-0/
We need to suppress C5038 warnings from Windows Runtime Library header files (wrl.h) included in ANGLE and widget/windows:
z:\build\build\src\vs2017_15.4.2\SDK\Include\10.0.15063.0\winrt\wrl\wrappers\corewrappers.h(515): error C5038: data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::sync_' will be initialized after data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::status_'
...
And suppress C5038 warnings in upstream webrtc code:
media/webrtc/trunk/webrtc/modules/video_capture/windows/BaseFilter.cpp(176): error C5038: data member 'mozilla::media::BaseFilter::mClsId' will be initialized after data member 'mozilla::media::BaseFilter::mState'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(169): error C5038: data member 'mozilla::media::BasePin::mFilter' will be initialized after data member 'mozilla::media::BasePin::mLock'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(170): error C5038: data member 'mozilla::media::BasePin::mLock' will be initialized after data member 'mozilla::media::BasePin::mName'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(172): error C5038: data member 'mozilla::media::BasePin::mDirection' will be initialized after data member 'mozilla::media::BasePin::mQualitySink'
MozReview-Commit-ID: BMDVkvQXNoq
--HG--
extra : rebase_source : 0d5ede9530d0d0750b8fffdc1cdfdc646ec8f22a
Environment variables for configure don't get automatically propagated
down to js/src on Windows because mingw. So we have to take extra steps.
--HG--
extra : amend_source : fc123e7439ebbf97884eeb56af8409c7b3294b21
This change ensures that folks who configure --with-system-FOO for
various values of FOO can build Stylo, since bindgen will know where to
find the flags for said FOO packages.
Add an intermediate step in old-configure.in for setting up
BINDGEN_CFLAGS (renamed to BINDGEN_SYSTEM_FLAGS), so we can add whatever
flags we like (e.g. for system libaries with their includes in
non-standard places) at a later point.
This class isn't being used right now, and MozURL is a much better alternative if interaction with rust URLs is required.
MozReview-Commit-ID: ADdYRrrTnr6
--HG--
extra : rebase_source : b36aa26c20e7daaadab1f3360bab0ed4681eb7f8
The system ffmpeg will be used instead or libvpx if not found.
MozReview-Commit-ID: GX5WWPOhPq9
--HG--
extra : rebase_source : 3eec2ee1bc3b66d88653b913d6d1b3ad1a5d5acd
Backed out changeset f019d4ffff53 (bug 1414735)for failing Gtest TransportTest.TestCipherMismatch and Xpcshell dom/presentation/tests/xpcshell/test_tcp_control_channel.js tests on a CLOSED TREE r=backout UPGRADE_NSS_RELEASE
Remove the VP8 and VP9 decoder and the subsequently unused functions.
This drops the size to libmozavcodec to around 1MB down from 4MB.
MozReview-Commit-ID: Ge57fauG35L
--HG--
extra : rebase_source : 3f667d7bf89036e9b059727d846af2504ce488b3
For now this is a C decoder only and FFmpeg isn't optimised to only decode flac (both vp8 and vp9 C decoders code is included, however they aren't enabled).
MozReview-Commit-ID: 7ulwvJDJqVg
--HG--
extra : rebase_source : 7090eee32ba394224ef8c3c1c31abf1543b69975
This also introduces C{XX}_LDFLAGS variables which contain cflags that
are meant to be passed to the linker, and adds them to various linker
command lines in place of CFLAGS.
MozReview-Commit-ID: GyKlD9nMqrt
This commit establishes a separate variable to add PROFILE_GEN and PROFILE_USE
CFLAGS to compile and link command lines. Currently the make backend
orchestrates the pgo build steps and is the only thing aware of whether
we're in the profile generate or profile use stage. The flags are separated
here to allow other flags to be moved to mozbuild, but this will not yet
sufficient to perform a PGO build independent of the make backend.
MozReview-Commit-ID: IX30l2MvvNc
When we move to a shell aware split for AC_SUBST_LIST it will become an error
to emit an unquoted make variable reference. Currently this happens to only
occur during artifact builds when setting cflags related variables that aren't
needed there anyway, so here we skip settting those variables when a compile
environment isn't present.
MozReview-Commit-ID: EnHu48yyZ1C
The Rust optimization logic is tied to --enable-optimize/MOZ_OPTIMIZE
and --enable-debug/MOZ_DEBUG. In order to more easily implement more
customization, let's move --enable-optimize/MOZ_OPTIMIZE to
moz.configure so its value can be consulted there.
The logic here is a bit wonky. The option behaves like a boolean
or a string. If a string, MOZ_OPTIMIZE is set to 2. Otherwise it
is 1 or unset depending on the boolean value.
The custom compiler flags string is passed to old-configure, where it
overwrites whatever old-configure derived as the default value.
We stop short of moving all references to MOZ_OPTIMIZE_FLAGS to
moz.configure because there are a handful of them and I don't want
to scope bloat.
MozReview-Commit-ID: 6iNDu2HwLGr
--HG--
extra : rebase_source : a64f1236012d13913f21253df1b9b5ff0ae8ea6e
It is now closer in the file to where other default values are computed.
MozReview-Commit-ID: BffCEb6FAUP
--HG--
extra : rebase_source : 81b17131f9330d89818a36ffff625b672c19c01e
Bug 1365460 introduced code paths behind MOZ_DEBUG #ifdefs, but
MOZ_DEBUG is never defined, while it is available in CONFIG in
moz.builds. This is kind of a confusing situation, but the fact that
we've been able to avoid those problems for so long would tend to
put the blame on mozjemalloc, and fixes should go there.
Except that bug 1261161 explains that the only existing alternative
(the DEBUG #define), as used in MFBT, is not working for spidermonkey,
so it actually makes sense to converge to MOZ_DEBUG rather than DEBUG.
So start defining MOZ_DEBUG globally, fixing the mozjemalloc issues of
not having the debug code enabled. Bug 1261161 can then take care of
changing the DEBUG #ifdefs.
--HG--
extra : rebase_source : 37e3d03ac8350c62c8059d4ca01d1ecfdf5f421a