We need this so that Python comtypes can generate bindings for IAccessible2.
This is almost identical to what was here before, but it excludes some stuff that was only needed for the COM interceptor.
Differential Revision: https://phabricator.services.mozilla.com/D187745
This includes AccessibleHandler, HandlerProvider, IGeckoCustom and the IAccessible2 COM proxy dll.
Even with the new architecture, we still use IAccessible2, but we no longer need a COM proxy because we aren't using COM across processes ourselves.
If clients want to use IAccessible2 across processes, they're responsible for registering a COM proxy themselves as with all other IAccessible2 applications.
Alternatively, they can rely on the IAccessible2 COM proxy which is included with Windows 10 and later.
Differential Revision: https://phabricator.services.mozilla.com/D177963
This includes AccessibleHandler, HandlerProvider, IGeckoCustom and the IAccessible2 COM proxy dll.
Even with the new architecture, we still use IAccessible2, but we no longer need a COM proxy because we aren't using COM across processes ourselves.
If clients want to use IAccessible2 across processes, they're responsible for registering a COM proxy themselves as with all other IAccessible2 applications.
Alternatively, they can rely on the IAccessible2 COM proxy which is included with Windows 10 and later.
Differential Revision: https://phabricator.services.mozilla.com/D177963
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
It was only ever set to the same value as its default, except in
comm-central, where it is unset, but in directories that now don't link
anything (they did back when binary components were a thing).
Differential Revision: https://phabricator.services.mozilla.com/D85381
It was only ever set to the same value as its default, except in
comm-central, where it is unset, but in directories that now don't link
anything (they did back when binary components were a thing).
Differential Revision: https://phabricator.services.mozilla.com/D85381
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--HG--
extra : moz-landing-system : lando
This is an alternative to carrying a revert of the offending changeset, since the bug doesn't show hope of a fix anytime soon, or maybe ever. This way we don't have to keep rebasing the patch as we pick up new clangs, and developers don't have to remember to apply the patch when building a local compiler.
Differential Revision: https://phabricator.services.mozilla.com/D59200
--HG--
extra : moz-landing-system : lando
This patch contains three fixes.
1) As in Bug 1515982, we use the constant for RT_MANIFEST instead of
the define, which needs winuser.rh to be included
2) We stop exempting the mingw builds from RCINCLUDE in
toolkit/library/moz.build which causes us to miss all of the
resources in xul.dll
3) We explicitly include IA2Marshal.dll instead of relying on
compiler magic to include it for us.
Differential Revision: https://phabricator.services.mozilla.com/D26295
--HG--
extra : moz-landing-system : lando
All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
When an idl file is updated, files like HandlerData.h are generated as
part of the midl target (eg: midl_done). However, Make may have already
stat'd HandlerData.h and cached its timestamp. Although there is a
dependency from HandlerData.h on midl_done, there is no recipe. As such,
Make assumes that HandlerData.h hasn't actually changed, and uses the
cached value of the timestamp when determining if it should install the
file into dist/include. If the cached value is older, make may not
trigger the install rule, leaving the old header in place and breaking
the build.
MozReview-Commit-ID: 9rdtXIt8mXC
--HG--
extra : rebase_source : 8b22f1d6656d0dbc2c3b5dc53ea2b936fdd637bd
Trevor, please read comment 1 in the bug for some discussion around the idl files in this patch.
MozReview-Commit-ID: Emos5mLuobS
--HG--
extra : rebase_source : fc445e2257536d55c0ddefca944152930d261272
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
The Windows MIDL code generator creates things like:
#endif !_MIDL_USE_GUIDDEF_
which clang-cl complains about. MSVC doesn't, so turn this warning off.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.