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.
They were behind WANT_MOZILLA_CONFIG_OS_VERSION, which nothing has been
setting ever since the ifdef was changed from
MOZILLA_CONFIG_IGNORE_OS_VERSION... in 2000. Not that anything was
setting MOZILLA_CONFIG_IGNORE_OS_VERSION either... well, at least not in
Gecko.
We can just generate xpidllex.py/xpidlyacc.py in the current directory
rather than one directory higher, and specify this directory as an
include path to xpidl-process.py
MozReview-Commit-ID: KLoGjudc4Y8
--HG--
extra : rebase_source : 8dda268c6490cdfb8b896de9da5b789208584193
-Zi is already set through MOZ_DEBUG_FLAGS, which is set from
--enable-debug-symbols, which is the default, and if someone goes all
the way to explicitly disable them, we might as well not silently
override their decision.
-Od disables optimization, and the given reason was for sane stack
traces, but the fact is we're currently building debug builds, which
have been optimized by default for a while, and are the only ones with
DMD enabled by default, without overriding with -Od and are apparently
happy with it.
-DNDEBUG is already set through MOZ_DEBUG_DEFINES, and -UDEBUG is not
doing anything useful, since nothing is setting DEBUG on the command
line, nor does the compiler by default.
The flag is used to create .sbr files, which bscmake subsequently uses to
create .bsc files. These files and related tools are, aiui, the ancestors
of Intellisense.
The -FR C*FLAGS are added to the build if MOZ_BROWSE_INFO or MOZ_BSCFILE
are set in the recursive make backend. While the former has an AC_SUBST,
the latter does not, so in practice, only the former can be set by
supported methods, and would need to be set in a mozconfig. At that
rate, people who do want those flags can add them in the C*FLAGS on
their own.
Developers are probably better served by the VisualStudio backend
anyways.
We don't really care to set those in js/src/configure because the JS
engine doesn't use ObjC. We also don't care to preserve the += behavior
because there were no AC_SUBST in the first place, so it's unlikely
anyone has an override in their mozconfig and expects it to work.
Limit ourselves to include paths for now, because there are tricky things
involved in making this globally.
While here, use shell_quote instead of manual quoting for those paths.
This might seem like going in the opposite direction of what we tend to do
to move to moz.build land, but those flags are irrelevant in many situations
and are better separated out.
MOZ_DEBUG_DEFINES are essentially defines used everywhere. So treat them as
feeding the initial value for DEFINES in each moz.build sandbox. This allows
the kind overrides that was done in the past by resetting MOZ_DEBUG_DEFINES
in Makefiles.
This patch moves the logic for selecting MOZ_WINCONSOLE out of individual
Makefile.in files and into configure. It also changes config.mk to only
pass -SUBSYSTEM:CONSOLE if MOZ_WINCONSOLE=1. The MSDN docs state that
in the absence of -SUBSYSTEM, the linker will select the proper subsystem
based on whether the program contains [w]main or [w]WinMain, so let it
do that.
One program (windbgdlg) needed a tweak to add a wmain for when MOZ_WINCONSOLE
is defined.
This patch leaves one instance in security/sandbox/win/wow_helper/Makefile.in,
that Makefile has its own separate bug.
--HG--
extra : commitid : 8acDjmfKivj
extra : rebase_source : 03b4fa4c8ae077a894b08f3762ef93541e34ac1a
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.
The flags added in toolkit/locales/Makefile.in turn out not to be actually
used, so just remove that.
The remaining uses of XULPPFLAGS are to set debug flags depending on whether
MOZ_DEBUG is set or not. Just set a dedicated variable with the right value
from configure.
At the same time, make the test for libstdc++ more comprehensible.
--HG--
extra : commitid : FY4SOJob69k
extra : rebase_source : 15778a2080423666edeae78adb7a5b80925f6871
Its only purpose is to disable PGO. Where that was not already explicitly done,
or irrelevant (because the directory only contains python), I disabled it in
moz.build.
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
Optimised Rust compilation is enabled on passing --enable-optimize to
the configure script. This sets the RUSTFLAGS output variable that gets
picked up by the compile targets RSOBJS and RSSRCS and passed to rustc.
r=glandium
--HG--
extra : commitid : 8thSkfLFXSY
extra : rebase_source : 5ec79b76a187bcbb0f09ad374cf9f763f0adb0d7
Gregory Szorc
Mike Hommey
Nathan Froyd
Carsten "Tomcat" Book
Ralph Giles
Chris Manchester
Ted Mielczarek
Mike Shal
Ms2ger
Phil Ringnalda
David Major
Nicholas Nethercote
Nathan Froyd
Andreas Tolfsen
Ryan VanderMeulen