This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict. Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
Configure uses the value of the MT environment variable before falling back
to mt(.exe), but the build system was completely ignoring the MT
environment variable.
--HG--
extra : rebase_source : 8c9b43aeb08493ae5bd6d6361f4f18f097ea0553
Gpsd is the GPS daemon on Linux. It implements support for a wide range
of GPS receivers. This patch adds support for gpsd to the Geolocation
module.
The build system can now test for libgps, which provides the public
interface to gpsd's functionality. If found, |GpsdLocationProvider|
is added to the build.
MozReview-Commit-ID: 1kBgFdEZePI
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
B2g came with its own version of 'libgabi++' in its toolchain. Gecko
on b2g isn't build any longer with this toolchain. With this patch
applied, Gecko's internal version of 'libgabi++' is used for building.
MozReview-Commit-ID: KU4OBYQ6cAW
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 22ab4f47661ead4995d0c5261104abfb02b82aa2
Previously this implementation would use the expected names of the built-in
module and slot to get a handle on them. This doesn't work on distributions that
use other names. The new implementation searches through the slots from the
default module list for one where PK11_HasRootCerts returns true (which
indicates that NSS considers that slot to contain the default built-in root
list).
MozReview-Commit-ID: LmX27hQfFJU
--HG--
extra : rebase_source : 50383dcc77257fe08ce2c7d908e95cda7c4bbe9d
This also fixes the issue of processing the artifacts twice in some
situations (bug 1275673). Note that the artifact download no longer
happens when a specific target is passed to 'mach build'.
MozReview-Commit-ID: Ktys6u3r1kG
Historically, a mozinfo for js standalone build has not been necessary,
but with the move towards a) having things work with mach and b)
buildconfig using the MozbuildObject.from_environment in next patch,
mozinfo becomes necessary (it's required for
MozbuildObject.from_environment to find the directory is an objdir).
Interestingly, hazard builds do both a js standalone build and a desktop
Firefox build at the same time, both of which are done with MOZCONFIG
set in the environment... with the Firefox mozconfig. The result of now
writing a mozinfo for js standalone builds is that in that case, they
end up with a reference to the mozconfig, which the build system then
reads, and finds a MOZ_OBJDIR, which then doesn't match the js
standalone build objdir. So for those builds, reset MOZCONFIG.
Until now, we had some STL headers listed in the system-headers list
such that they would get a system wrapper, but not all of them.
On the other hand, the STL wrappers do the same job as the system
wrappers (applying default visibility), on top of their own, so the
presence of the STL headers in system-headers wasn't making much of a
difference.
Except we have places in the tree where we can't build with STL wrappers
for a number of reasons. And in that case, we *do* need system wrappers
for the STL headers, but we didn't have system wrappers for all of them.
So instead of relying on the STL headers being listed both in
system-headers and stl-headers, concatenate both lists to create the
system wrappers.
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.
This uses a rough form of prefix matching, considering anything that ends in a
path separator and appears as a prefix of a file to be a directory.
MozReview-Commit-ID: 7FJSxI0fBSA
--HG--
extra : rebase_source : e4cece21a25ac1216d96647963955459d0f964e5
By bug 1270621, ETW support is removed. So no one uses messege compiler.
MozReview-Commit-ID: HGUAkrb208N
--HG--
extra : rebase_source : 5178283b781e4805b4e97f09b35a4150119d060a
extra : histedit_source : 40d6992894315b51863db4e7697df1c1ef18edd8
The intent in bug 1271829 was to make all the XCFLAGS set in
config/external/nss/Makefile.in accumulate instead of replacing each
other. Unfortunately, there is also an AC_SUBST variable named XCFLAGS,
use for other purposes, and we ended up adding on top of that variable.
Using a different local variable allows to still accumulate the values,
while keeping away from the XCFLAGS from autoconf.mk.
Since the introduction of the STL wrappers, they have included
mozalloc.h, and multiple times, we've hit header reentrancy problems,
and worked around them as best as we could.
Taking a step back, all mozalloc.h does is:
- declare moz_* allocator functions.
- define inline implementations of various operator new/delete variants.
The first only requires the functions to be declared before they are used,
so mozalloc.h only needs to be included before anything that would use
those functions.
The second doesn't actually require a specific order, as long as the
declaration for those functions comes before their use, and they are
either declared in <new> or implicitly by the C++ compiler.
So all in all, it doesn't matter that mozalloc.h is included before the
wrapped STL headers. What matters is that it's included when STL headers
are included. So arrange things such that mozalloc.h is included after
the first wrapped STL header is fully preprocessed (and all its includes
have been included).
It turns out that, since we're including <new> before setting
_GLIBCXX_DEBUG, the debug parts of c++config.h are not activated, and
that has an impact of how much of the debug features of the STL are
activated.
In contrast, the upcoming changes to the STL wrappers are avoiding the
include of <new> before _GLIBCXX_DEBUG is set, which in turn breaks the
build because, as we link things that use STL wrappers with things that
don't, they end up with a different state of STL debugging, and have
mismatching symbols.
Nathan Froyd
Xidorn Quan
Mike Hommey
ffxbld
Carsten "Tomcat" Book
Eugen Sawin
Thomas Zimmermann
Tom Tromey
Rob Thijssen
Damien Zammit
Luke Wagner
Andrew Comminos
Gregory Szorc
Wes Kocher
Ted Mielczarek
David Keeler
Mike Shal
Dustin J. Mitchell
Makoto Kato