security/ is already skipped through top-level moz.build. For
convenience, we skip the DIRS that end up adding GYP_DIRS, avoiding
reindenting their entire moz.build.
--HG--
extra : rebase_source : 346aba5f4ec29112cb2ce035844e57f13a214482
It is technically possible to move it even further up with adjustments
to the top-level moz.build, but that would either be too hackish, or
more involved (and possibly risky for other targets), so I'd rather
keep that for a followup.
--HG--
extra : rebase_source : f70a9a69d8ddba3d60bd09300752d0f41a4c7cac
It is technically possible to move it even further up with adjustments
to the top-level moz.build, but that would either be too hackish, or
more involved (and possibly risky for other targets), so I'd rather
keep that for a followup.
--HG--
extra : rebase_source : 11048687e6c56f528fe4f674c8b951630a10aebd
geckodriver compilation was disabled by default in
https://bugzilla.mozilla.org/show_bug.cgi?id=1368084 due to issues
building it locally on Windows.
This re-enables building of geckodriver in automation, but gives
developers an option, --enable-geckodriver, to opt-in to building
it locally.
geckodriver is implied on supported platforms when MOZ_AUTOMATION is
set, but we also provide the option for developers to use. This means
geckodriver will be built in CI by default, but not in developers'
local environments.
MozReview-Commit-ID: ACkO97ekVsi
--HG--
extra : rebase_source : 067e25911f72d80a54e662f24cc71dedde53a4e1
geckodriver fails to cross-compile on the TaskCluster x86_64 VMs to
Linux i686. This patch disables building on that platform, and I have
filed https://bugzilla.mozilla.org/show_bug.cgi?id=1367519 to follow up
on this.
MozReview-Commit-ID: 7GEx2Oog2fS
--HG--
extra : rebase_source : ed722e066a4de1e4bd73c32ba98aed8916c34fd2
One of the Rust crates that is built as part of geckodriver's dependency
chain uses a build script to compile some C code.
Because mozbuild does not yet pass the compiler wrapper down to where
the gcc crate can find it, we need to avoid building on geckodriver when
this is the case.
When compiling the browser for the rooting hazard analysis build (labelled
H on Treeherder), the MOZ_HAZARD environment variable will be set and
available to moz.build descriptions.
MozReview-Commit-ID: GprFKtvXvOE
--HG--
extra : rebase_source : f45aa5d8c86673c8287371efcfa703755c2b2073
geckodriver is the Mozilla implementation of the WebDriver remote
control interface for Gecko, and provides an HTTPD proxy that
translates the WebDriver protocol to Marionette.
Building this as part of the Firefox build will allow us to run
WPT WebDriver tests to verify our implementation of Marionette and
geckodriver. It also makes it less painful to make changes across
projects.
This change will cause the geckodriver program to be built as part
of regular Firefox builds, except on macOS and Android, and when artifact
builds are enabled.
RUST_PROGRAMS in cross-compile environments cause the wrong linker to
be used. When this bug is fixed, we should be able to enable building
of geckodriver on macOS. This work is tracked in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1329737
On Android, we may one to build a binary for the host system to use
(x86_64), instead of an ARM binary for the emulator.
MozReview-Commit-ID: FG5tmPv4iut
--HG--
extra : rebase_source : 091728fd2582458325689fc6e3d8b317428802d8
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Its content is a no-op since bug 1322707.
The code in the same directory, though, is meant to move to gtests
(bug 1316611).
--HG--
extra : rebase_source : fa269a034fd327856fde8d0673de58eba9b02d8e
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : fe3c9480cee468aa2a24fd34e569b58e4f2c9c9a
By including the mozbase's moz.build directly in the root moz.build, we are making sure that
mozbase unittests will be found even if there is no build/objdir. This will be useful when
running mozbase tests in their own taskcluster task.
MozReview-Commit-ID: DqqY09I3JBC
--HG--
extra : rebase_source : 46c2386e3a6fc2106f8277fde1363e4c28457d0f
This patch tries to do three things:
1) Replace the ENABLE_MARIONETTE entrypoint with --enable-marionette.
2) Fold the default value -- forced on unless building for target OS
Android or building with toolkit gonk -- into the flag, rather than
embedding that condition in the tree.
3) Stop using AC_DEFINE and instead use only AC_SUBST, so that no
compiled code needs to be rebuilt if the flag is flipped locally.
n.b., each installer/Makefile.in knows that ENABLE_MARIONETTE is set
(in order to set -DENABLE_MARIONETTE=1 for
*/installer/package-manifest.in) due to it being an AC_SUBST.
MozReview-Commit-ID: AkkmybyP1uI
--HG--
extra : rebase_source : c2c8b268c60350ff39d872cee357b53f17e79eef
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.
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.
fix_stack_using_bpsyms.py locates a .sym file based on file name only, not uuid or full path,
which causes a failure if a duplicate leaf file name is introduced. This patch introduces a
small utility program on mac and linux to extract a breakpad guid from a shared library or
executable to identify the correct symbol file when this ambiguity occurs. A subsequent commit
implements this for windows.
--HG--
extra : commitid : 2O7REfHuDus
A new configure option --with-devtools (which sets MOZ_DEVTOOLS) is added to
control whether all DevTools, just the server, or no DevTools are included.
This defaults to just the server.
Applications should also include /devtools within their moz.build tree, so that
DIST_SUBDIR is in effect for all DevTools files if it is used by the app.
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.
This step resumes shipping client and server DevTools components to the correct
products, and is enough for "mach build" to complete successfully.
--HG--
extra : commitid : In5fMWBRKUy
extra : rebase_source : b7d92da9c6795275e5026b8e9e56d9487985b69f
Mike Hommey
Sebastian Hengst
Andreas Tolfsen
Ralph Giles
Ehsan Akhgari
Ehsan Akhgari
Iris Hsiao
Andrew Halberstadt
Myk Melez
Nick Alexander
Ryan VanderMeulen
Eric Rahm
Christian Holler (:decoder)
Henrik Skupin
Nathan Froyd
Wes Kocher
Makoto Kato
Chris Manchester
Mike Conley
Kit Cambridge
J. Ryan Stinnett
Kan-Ru Chen
Daniel Stenberg
Nicholas Nethercote
Birunthan Mohanathas
Randall Barker