We have a new remote protocol in Firefox that is based on the Chrome
DevTools Protocol (CDP). This is a low-level debugging interface with
which you can inspect the state and control execution of documents
running in web content, instrument Firefox in interesting ways, simulate
user interaction for automation purposes, and debug JavaScript execution.
This patch hooks the server part of this implementation, known as the
remote agent, up to the build system. The remote agent is not enabled
in the default build, so the following is needed in mozconfig to build it:
ac_add_options --enable-cdp
A subsequent change to enable the remote agent in Nightly builds only
will follow in due course. That would allow us to run TaskCluster
test jobs to verify the remote protocol's functional integrity.
Differential Revision: https://phabricator.services.mozilla.com/D22729
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : source : abd7789e9637c92978efcf745361b98c5abf847a
extra : intermediate-source : 276ca640adc8ff16ff3ff7252e8aa5016205b1e0
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : rebase_source : f33e1ad19c1ed06fc79e017d62765a7632578258
extra : source : abd7789e9637c92978efcf745361b98c5abf847a
Fennec has a value of OMNIJAR_NAME that contains a directory, contrary
to other platforms, and relies in post-packaging, pre-unpacking steps to
accommodate with the difference.
With this change, we just make the packaging and unpacking steps aware
of this setup, and make allow them to pack/unpack resources in foo/
under foo/$OMNIJAR_NAME, whether $OMNIJAR_NAME is a file name or a path.
This will, further down the road, allow the packager code to handle jar
logs from PGO instrumentation without munging them.
Differential Revision: https://phabricator.services.mozilla.com/D21654
--HG--
extra : moz-landing-system : lando
And remove the manual --enable-dmd in in-tree mozconfigs, as well as
--enable-profiling, which is implied by --enable-dmd.
This disables DMD on add-on-devel builds, which don't look like they
were actually meant to have DMD enabled in the first place (they only do
because they use the nightly mozconfig on all branches, and as a matter
of fact, the nightly mozconfig didn't enable DMD before bug 1409739)
This enables DMD on mingw builds with the same conditions applied as
other platforms, meaning that it's not enabled on opt builds on release
branches.
And this enables DMD on plain builds, which, from this perspective,
reflect local developer builds, and this is the expected effect.
Depends on D21161
Differential Revision: https://phabricator.services.mozilla.com/D21162
--HG--
extra : moz-landing-system : lando
It used to be that --enable-eme on its own had some effect, but that's
not the case anymore. The only thing it does as of bug 1300654 is to
switch the defaults in the Firefox configuration.
Reflect that in how we handle --enable-eme.
Differential Revision: https://phabricator.services.mozilla.com/D20270
Accessibility now compiles and works, so we can re-enable it!
This effectively backs out the moz.configure part of 02cd44e39566.
Differential Revision: https://phabricator.services.mozilla.com/D19650
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
AV1 is actually enabled everywhere by default (except 32-bits Windows
when building with MSVC), so let's make the option --disable-av1 rather
than --enable-av1. Also, since AV1 is backed by both libaom and
libdav1d, remove mentions to libaom.
Differential Revision: https://phabricator.services.mozilla.com/D18294
--HG--
extra : moz-landing-system : lando
AV1 is actually enabled everywhere by default (except 32-bits Windows
when building with MSVC), so let's make the option --disable-av1 rather
than --enable-av1. Also, since AV1 is backed by both libaom and
libdav1d, remove mentions to libaom.
Differential Revision: https://phabricator.services.mozilla.com/D18294
--HG--
extra : moz-landing-system : lando
We reenable the corresponding tests unconditionally because we don't run
tests on the msvc builds anyways (and they're going to be retired soon).
Differential Revision: https://phabricator.services.mozilla.com/D18028
--HG--
extra : moz-landing-system : lando
This aggregates a list of all static component manifests in the tree, and
writes them out to a `manifests-lists.json` file, which is read by the codegen
scripts in the next patch.
It slightly abuses the IDL lists machinery, given that these aren't
technically IDL files. But the semantics are similar enough that it seemed
like the best option.
Differential Revision: https://phabricator.services.mozilla.com/D15034
--HG--
extra : rebase_source : f1e1e1c9497ab8c18c25a106316a1af57237b99f
extra : source : f500020a273a27c66bf2166505a0e97bbc34a214
In some setups, MSVC is not found through vc_compiler_path, so we may
need a more complete path. `toolchain_search_path` contains
vc_compiler_path, as well as $PATH (among others), increasing our
chances.
Also, if we fail to find cl.exe that way, fail early, instead of failing
while processing config.status, failing to serialize MIDL_FLAGS because
it contains a `None`.
Depends on D17767
Differential Revision: https://phabricator.services.mozilla.com/D17768
--HG--
extra : moz-landing-system : lando
This turns out to not work at all, because this prevents MIDL itself to
pass -I to the compiler, which then proceeds to fail. We're just lucky
that our MSVC detection doesn't yield any default flags so this is
effectively dead code.
Differential Revision: https://phabricator.services.mozilla.com/D17767
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
Differential Revision: https://phabricator.services.mozilla.com/D16778
--HG--
extra : moz-landing-system : lando
This also moves the corresponding ASFLAGS from moz.build to python
configure.
Differential Revision: https://phabricator.services.mozilla.com/D16320
--HG--
extra : moz-landing-system : lando
MOZ_D3D_CPU_SUFFIX and MOZ_HAS_WINSDK_WITH_D3D are not used in the
build, and nothing includes d3d10.h except some angle code in a
preprocessed branch that is only taken for a macro we never define,
so we don't move the code corresponding to those. We also simplify the
detection code, which is convoluted now that it doesn't search for
multiple different DLLs.
Differential Revision: https://phabricator.services.mozilla.com/D16295
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
