This accounts for LOCAL_INCLUDES in the moz.build files, as well as the
default INCLUDES specified in config.mk that are used for host
compilation. Since some of the HOST_CFLAGS were also used for linking,
those flags are split off into HOST_C{XX}_LDFLAGS so that
the linker-only flags can be placed in those variables.
MozReview-Commit-ID: J1LxIZVeFJ
--HG--
extra : rebase_source : ed7293604e5428e3124f1ecfb2b706e087436b72
Both SFLAGS and ASFLAGS are used to compile assembly, but SFLAGS include
DEFINES and LOCAL_INCLUDES whereas ASFLAGS do not. It seems easiest to
just separate them into two different ComputedFlags values so that the
backend can distinguish between the two types.
MozReview-Commit-ID: Bkm3621ImJG
--HG--
extra : rebase_source : 420204e37d591512f700d77b780939d20c2feeb0
The make backend is the only thing that is aware of PROGILE_GEN and
PROFILE_USE, so we move these ldflags to their own variable while
converting the remainder of ldflags to mozbuild.
MozReview-Commit-ID: GwbPD6Q4Oyn
--HG--
extra : rebase_source : 3c90def9ee8cd949dd135ba8fa9b192f114f6727
These flags are only relevant on OS X, and will not be necessary soon, so this
commit moves them to a separate variable while we move the remainder of the
ldflags to mozbuild.
MozReview-Commit-ID: 1NDgz3HIYpT
--HG--
extra : rebase_source : 6e9b5f5a5be5ff916db89a0b73896b9058eb040e
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : 00715beb5fbd2c11311dec43809bd1febab56a11
extra : intermediate-source : 0f2b1b75b83737378d882a3c3e0d8dfb4efecd1f
extra : source : a8032ae9cb2ad1c4574c6ac6f5c2778863cd71e0
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
Incremental linking is automatically disabled when -OPT:REF or -OPT:ICF are used.
Seeing that we're disabling optimizations anyway, may as well not use those linker flags as they considerably slow down linking.
MozReview-Commit-ID: 9OXG19uxeI9
--HG--
extra : rebase_source : 4703bc4bb62af3f054ca621be7c1c51fe56cb2f3
As we move our compile command lines into mozbuild we want to stop using DEFINES
directly. This patch adds a variable that can be set from Makefiles to contribute
defines to a compile command line to help the transition.
MozReview-Commit-ID: 5xLB06pzpJY
--HG--
extra : rebase_source : 7ca0b9d8f5a77ec55eb751f75f58a69e64efb21d
To not merge the en-US language pack, the merge-% steps are in
a conditional function that disables that for en-US. Using a function
here as that's easier than a shell if in the merge rule, and
Makefile conditionals don't get evaluated late enough.
To liberate the l10n builds from settings in the automation,
we move the patch logic from LOCALE_MERGEDIR to REAL_LOCALE_MERGEDIR.
To determine strongly when we're in a repack or building a langpack,
the trick here is to
export IS_LANGUAGE_REPACK
in l10n.mk, and only set that to true in the entry-point rules.
Now, we can use that value in config.mk to define the l10n-specific
rules.
I did the same thing for langpack-%, which allows us to disable
the crashreporter files for language packs, for example.
With that,
make installers-de
just works, if you have localizations checked out.
For a while, we might run l10n-merge twice in automation, but it's really not
optional, so let's just make sure we run it.
MozReview-Commit-ID: 3nr33CKxkBQ
--HG--
extra : rebase_source : 0605a4adba018fa4b85d563cdafba80b0533bc91
This is a similar issue to bug 582910 which the stack isn't big enough
to run the tests that recurse deeply. Set it 3x larger because the
offical site states they've seen up to 3x stack memory increase for
ASan, also the number was confirmed by the measurements in bug
1259796.
MozReview-Commit-ID: FLASlkVrEUM
--HG--
extra : rebase_source : 3e82439e3df7b1e2fa1759c9693bd197431c9f71
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : cc7e4346869b98a52840c101824044abc236637f
moz.configure only sets the color flags value for the target compiler.
If the host compiler is a different version and doesn't support color
flags, we may pass unrecognized command line options.
Until we have better distinction between host and target compilers
throughout the build system, just disable automatic color flags for
host invocations. We don't have too many host binaries, so this should
have negligible impact.
MozReview-Commit-ID: KWTLkKvtwHs
--HG--
extra : rebase_source : 97a7240a796bae42221b2952d4dc1e66294e6219
At the same time, remove HOST_LD. It was only used for MSVC builds,
which don't support cross-compile anyways, so we can, at least for now,
use LINK for both host and target.
--HG--
extra : rebase_source : 9ee9e7e1bd3edefc043fa63d5c03f2a242f76982
iTerm2 interprets the byte sequence "ESC [ 2 i" as a request to open
a print dialog. This sequence can get emitted when printing colorized
compiler output.
Until we figure out a workaround, disable automatic coloring on iTerm2
so developers aren't annoyed.
MozReview-Commit-ID: 3Be4YgArg4k
--HG--
extra : rebase_source : e4e441a6fd97b09f55b05d53af91890649249e1c
GCC and Clang will colorize compiler output automatically if stdout is a
TTY. Unfortunately, when the build backend is invoked via `mach`,
stdout is not a TTY.
6e9a4c0b9cd8 (bug 1315785) changed mach so it exports an environment
variable indicating whether mach's original stdout is a TTY. This was
later used to add color flags to `cargo` invocations.
Building on that work, this patch adds color flags to compiler
invocations if the compiler supports color and a mach TTY is
detected. The result is that compiler output from `mach build`
will be colorized automatically if Clang or a modern version of
GCC is used.
The only issue I see with this is that Clang doesn't "unset" its color
sequences when printing a newline. As a result, mach's time line
prefixing can sometimes inherit "bold" or other stylings. AFAICT this is
only a minor cosmetic concern. GCC does not exhibit this issue.
MozReview-Commit-ID: 5Icu6aXGZBL
--HG--
extra : rebase_source : 5b2bf5a287fdf8075b3d7dde36b91f3c65b60728
Now that we compile with cargo, we don't have fine-grained control over
the build flags used via environment variables detected in configure or
set in config.mk. We should just remove that dead code so nobody trips
over it.
The only use of this variable is to override NSINSTALL, and its value is
the same as NSINSTALL_PY.
While here, remove the outdated NSINSTALL_NATIVECMD that was used for
pymake.
--HG--
extra : rebase_source : b871fbb409836a17cb8d71cd1e5ddc9d5ad3f49f
Similarly to the considerations about glibc, the Linux compatibility matrix
(https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix)
tells us no distro with Gtk+3 3.4 has a version of libstdc++ older than
4.6.
The data in the matrix doesn't go to that level of detail, but Ubuntu
12.04 LTS, being the only one with version 4.6 (others have at least
4.7), it's worth noting it has version 4.6.3. Which means we can safely
require libstdc++ symbols version 3.4.16 (which were added in 4.6.1).
This will allow us to remove a lot of the stdc++ compatibility hacks.
The requirement for glibc has been set to version 2.7 for a long while.
Spidermonkey uses the pthread_setname_np symbol, which is only available
since glibc 2.12. So far, we've been fortunate that the symbol doesn't
end up in libxul, or tests that link to js directly, because the symbol
is eliminated as being called by effectively dead code.
There are multiple reasons why this is going to change, one of which
being changes to the way things are linked, that will make the linker
not eliminate that code in some cases. Another is that eventually, the
separation of build systems between js and top-level is going to fade,
and the glibc checks, which apply to all gecko binaries, will also apply
to js binaries. They currently are not happening, and would fail because
of pthread_setname_np if they were.
Taking a step back, as of version 46, the mozilla.org builds require at
least Gtk+3 3.4. Which means the requirements for the underlying system
have received a dramatic bump, and it's time to revisit the requirements
for binary compatibility.
I went through all my notes from all the recent times binary compatibility
has been considered, and put together a compatibility matrix on MDN from
that data as well as more recent data that I could find here and there,
about the major non-rolling-release distros (RHEL, Fedora, SuSE, Debian,
Ubuntu)
https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix
Considering the data there, none of the distros that have at least Gtk+3
3.4 have a glibc older than 2.13. The list of symbols that 2.13 provides
that 2.12 doesn't have is not large enough, though, to really care about
depending on 2.13.
Mike Shal
Chris Manchester
Andreea Pavel
Masatoshi Kimura
Ted Mielczarek
Sebastian Hengst
Henri Sivonen
Jean-Yves Avenard
Axel Hecht
Sylvestre Ledru
Mike Hommey
Ting-Yu Chou
Phil Ringnalda
Benjamin Smedberg
Gregory Szorc
Nathan Froyd
Carsten "Tomcat" Book